Yesterday, I posted about storing passwords in MongoDb. Thanks to some feedback on G+, I changed the hashing from hashlib to bcrypt. SHA and MD5 are apparently not as secure.

Also, when I switched to bcrypt, I found an issue with my get_credentials() function. When it gets data back from MongoDb, it gets the entire array, even though I specified username. It just so happens, when I was testing with the previous version, I was using the same test password and it was hashed the same way. Bcrypt hashes the password different each time it’s called, so when I switched, the passwords were never matching up.

Here’s the updated code:

 

UPDATED HERE

It’s been a while since I’ve posted. Not being a full-time programming, I get periods of time where I’m swapped with work and don’t get to do much coding or writing. Recently, I attended the Datto Partner Conference, followed by playing catch up, followed by my CEO coming to town, which means hunkering down and planning strategy, and finally catch up again. One cool thing I learned recently about Datto is they use python for their Shadowsnap agent. Pretty cool seeing python used in products we use.

Anyways, the reason for this post is I’m working on a project that requires a database. I started it with MySQL, but then decided I should check out some of the more modern databases. That led me to looking into MongoDB. For those of you not familiar, MongoDB is not a relational database management system. It store documents which are similar to a record in sql, but documents do not have to be strictly defined and populated. For example, you may have a users database. One user could have username, full name, and email address. Another user could have username, full name, email address one, and email address two. Also, you can embed documents within documents. For example, you could embed photos with name, description, tags, etc in the users document. It’s pretty cool stuff.

One of the things I needed to do was store usernames and passwords. In MySQL, you can use the password() function to hash the password and store it. From what I’ve read, MongoDB doesn’t have this feature, so you need to do it yourself. Since I first implemented this in MySQL, I had to figure out how to take the login information from a user, hash the password to match what’s stored in the MySQL database and compare it to authenticate the user. Having already did that, I figured why not just use that same method for hashing the password to store in MongoDB. The password would be hashed like MySQL’s password() function.

Here are some sample functions in which you can setup user logins that are specific to a company. This would be for a site or application that hosts a service for multiple companies. You can have duplicate usernames, because they are associated with the company document. The company documents are unique. You could easily change these to create user documents instead and have unique user logins.

If you have any questions or comments, let me know. This is the first time I’ve messed with MongoDB and still learning Python, so I’m sure there are some stupid mistakes. Don’t hesitate to point them out.

Oh yeah. The reason I had the Mongo connection lines in multiple functions instead of at the top of the file was with the app I’m working on, these were in a separate module. I called the functions from another python module.

Here’s sample output.

mongologin

As with most of my python programs so far, this was inspired by a real need I had with my day job. We manage our clients networks utilizing Labtech’s RMM. Part of this is patch management. One of our clients needed some type of monthly report showing what patches got installed. Unfortunately, there isn’t a great canned report in Labtech to show this.

Labtech uses Crystal Reports, so I’m sure I could make a report to display this. The problem is two fold with doing it this way. One, I don’t know Crystal Reports, and two, Crystal Reports is as fast as a 28800 modem (how did we survive those?).

Since I’m learning Python and haven’t done anything with database access yet, I figured this would be the perfect place to start.

To talk to the MySQL database, I’m using mysql.connector. Here’s the run down of what this script does.

First, I wanted the ability to store the login information for the database, so I used code I wrote in the past to encrypt this into a file.  I put this code into a separate file called encryptconfig.py, which I import into the ltpaches.py file.

Also, I wanted to play around with the argparser module, so I used that to create all the command line parameters. It definitely makes it a lot simpler than the manual way I’ve done this in the past.

One last thing of note. You’ll notice the get patches function looks a little cumbersome. The reason is a record isn’t based on a patch. It’s based on an install of patches. That can be 1 patch or 100 patches. The record is one record either way. What I had to do was split the field that shows the patches installed and make each one it’s own record in the list. I also had to exclude the line that says “Updates require a reboot”.

Once I got this working, I simply ran the script with the -sl parameter to save the login details to a file. Then I created a scheduled task to run it with the “-ul passphrase” parameter.

Here’s the code from ltpatches.py.

 

Here’s the encryption.py code.

 

 

 

 

To date, I’ve only been able to write little command line programs that I needed for various tasks like getting average latency between offices. Command line utilities are great for sys admins, and they are fine when it’s just something I need personally. As soon as you want to provide a utility to a regular user, you better put a GUI in front of them, or they are going to act like you asked them to play Tank in the Matrix.

The first gui app I built was an expansion of a command line app I wrote for exporting the Exchange Global Address List. The command line app exported it to CSV, which was all I needed for my purposes. I wrote it so I could email an updated email list for a client of mine to their offices in Shanghai, which has it’s own email system.

Having been asked about how to print out the GAL many times over the years, I decided to write a gui app for regular users and give them the ability to pick the fields they wanted. Here’s what the app looks like.

 

So how did I learn to write this? First I watched a couple basic Youtube videos and skimmed through this PyQt4 tutorial. The tutorial was great to give me an idea of how the code functions. It gave me a place to start, although I still felt like I was missing a lot. The best way for me to learn once I have a little understanding is to just jump in and get at it.

Now, I know some people might not like this, but I learned the fastest by jumping into QT Designer. After poking around, I quickly figured out how to draw up my screens.  OK, I have the screen designed. Now what?

I got stuck here for a second until I found out how to convert the file you create with QT Designer into a python file. You do that with the “pyuic4” command. Here is the command I used.

“pyuic4 -x -o pythonfilename.py qtdesignerfilename.ui”

The -x will put a main function in at the end, so you can run the script and get your gui. This isn’t necessary with the way you will eventually want to write your app. More on that later. The -o is to specify your output file name and the last file name is the QT Designer file.

Wow, I can launch the gui now, but guess what? I doesn’t do anything. How do I put code in to make it work. I remember when I learned a little VB back in school. It was simple in VB. Just double click the object and start typing your code. Not so with with Python. Well, back to Youtube in search of how to make buttons, checkboxes, etc work.

After watching a couple videos, I found that you need to put something similar to the following line of code into the function you have that sets up your ui.

Self is referring to the class itself. btnClose is referring to the close button I drew on the gui. Clicked is what action is being taken on the button and connect is what calls the action (function) you want to take. In this case, it’s going to call a function called buttonClicked. Now all you have to do is put the code in the buttonClicked function. I basically used this same line for every button, and then my buttonClicked function checks to see which button was clicked.

In this example, lets say you click the Close button. That calls the buttonClicked function, which will have something similar to the following if statement:

This gets the text of the button and compares it to see if it equals “Close”. If so, the program exits. Seems pretty simple right.

Once you see how to do something for one object, it’s easier to figure out the other ones. Two invaluable resources are the list of PyQt classes and the list of PySide classes. Using these two sites, you can pretty much figure out how to change objects, how to read their properties, etc.

One example of reading objects properties would be the check boxes for the fields in the above screen. All I did (not sure it’s the best way) was check the value of isChecked for each of the checkboxes when the Export button was clicked. Using if statements to see if they were checked, I built a list of the fields the user requested. Here’s the code.

I’m sure you get the idea. Now,let’s get back to what I was saying about not needing the execution code at the bottom of the python file. You do not necessarily need that other than to test out what the gui looks like. When you actually write your app, you’ll want most of your logic in a separate python file. To get the gui, you’ll import the python file you made with pyuic4. The reason you’ll want to do this is in case you want to change your gui. If you change your gui and run pyuic4 again, you are going to lose all your code. By keeping your logic code in a separate file, you can change the gui and run pyuic4 until your hearts content.

One last thing you are probably wondering is what’s the difference betwen PyQt and PySide. From what I understand, it comes down to licensing. I don’t think I’m knowledgeable enough to talk about functionality. PySide has a much more flexible licensing model. The nice thing is they are very much a like. If you write your app in PyQt and want to change, simply change your import statements, and you should be able to get almost everything to work. I had a few exceptions.

On the second app I wrote, I had password fields. Changing the echo for the password field is different between the two, but not significantly. You just have to hit those two sites I listed above, and you can figure out the differences. I’ll be writing more about the second app here shortly and posting code. You’ll get to see PySide in action.

As always, let me know what you think. I learn a lot by just jumping in, but I’m sure I do a lot of bad things as well.

 

Before I get too far into writing posts about code I’m playing around with and the latest learning resources I’m using, I wanted to touch on what resources I found very useful to get started.

Depending on your background, you might need to take a different path. I had programming classes in my college days and tend to be fairly analytical. With that said, I can understand the basic flow of code and have been able to troubleshoot other peoples code periodically as part of doing network/systems administration. Because of this very basic understanding, I started learning using the videos over at TheNewBoston.

The videos from the new boston are pretty good to familiarize yourself with the language. I’d say it’s like learning words in high school foreign language classes. By the time you are done, you’ll know some good basics, but you probably won’t be able to do anything spectacular with it unless you already know programming and you’re just picking up a different language. I’m not trying to knock the videos. They are quick and to the point. They are a great way to get ready for the next resource, Google’s Python Class.

With the familiarity of the basics from the new boston, you will be able to follow Nick Parlante as he takes you though training and exercises that will have you writing real code. The exercises are what really separates the Google videos from the other tutorials online. They are fairly challenging, although maybe that’s more reflective of me than the actual exercises. The exercises have you add your code to the python files you download from the course website. The cool thing about the files is they have test functions built into them so after you add your code and run it, the exercise will check and see if it gets the correct information back.

The exercises start off with string functions and by the end of the training you are grabbing html from the web, doing regular expression searches through it, grabbing pieces of a puzzle and building the puzzle by assembling them in the right order and outputting the layout via html. When completed, if you open you html file and see the proper image, you completed the exercise successfully. These exercises were actually extremely fun and you learn a lot.

After using these two resources, I jumped into write a few things for work. I wrote the following:

1. A script that takes a Dell service tag and returns the warranty expiration date. This can be used to go through all the Dell workstations and servers that we manage and populate our database with warranty expirations so that we can inform clients of the approaching expiration. Typically, clients don’t renew the workstations, but they do typically renew the servers. That’s some extra sales that we might have let slip by. I did not get to the database portion yet, as I haven’t learned that part of python yet. I’ll add onto this later.

2. A script that exports all the contacts from the Global Address List in Microsoft Outlook. For one of our clients, I had to export their address list using the get external data function in Access. Then I’d export it to Excel. Lastly, I’d have to clean it up as it would include a bunch of garbage and email addresses weren’t formatted properly. This took probably 30-45 mins each time, and I had to do this monthly to send it to their office in Shanghai. Now with the script, it takes 20-30 secs and anyone can do it.

3. Next I started writing some code to go through our PSA to find workstations for a client that is no longer with us and changing their workstations to inactive. After banging my head against the wall for a few days, I finally was able to talk to the API and get the workstation IDs back. I thought all I had to do now was change the XML to the appropriate format to update the workstations and send the XML string back the same way I got the workstation IDs. Unfortunately, I was mistaken. I played with the updating portion for another day and then decided to hold off till I learn a bit more about XML and Python. I had another task that would help us, so I moved on to it.

4. Lastly, I wrote a script to access our disaster recovery system via the provided API and grab the backup status of each server for each client via XML. Then it formats an email with each client broken out with their servers, the current backup status and the last successful backup date and time. This saved us from having to login and drill down on each client every day. It also prevents us from forgetting to look if we walk into firefighting first thing in the morning. No matter what, you always end up going through email.

Before I moved on to other things, I felt I needed to learn more. Coursera had a class coming up called Crafting Quality Code. I figured I’d try that next. I’m just getting started in the class, but so far, it’s fairly interesting. I bought the book that the professors who teach the class wrote, Practical Programming (2nd edition): An Introduction to Computer Science Using Python 3 as it goes with the class. I’m also working my way through that. I’ll put a post out on the book when I’m done with it.