In this post, I’ll be talking about the personalization steps covering the differences between Michaels’s text and the steps to do the same in Xubuntu. As I stated in the last post, I’m building a new OSINT Investigations VM based on Michael Bazzel’s book. In the previous post, I covered the differences between his book and my choice of using Xubuntu instead of Ubuntu.
In the latest edition of his book, Michael Bazzell has decided to teach OSINT investigators to be self-sufficient when it comes to their tools. Gone is his OSINT powerhouse VM Buscador. Gone are the free tools he used to host. Instead, because things change and disappear, he has decided to teach people to build their own tools.
He uses Ubuntu as the base for the Virtual Machine in the walkthroughs. I didn’t care for Ubuntu, mainly because I’m not too fond of the default desktops. Honestly, I prefer running Debian with XFCE. But for quick installations, I go with Xubuntu. I say quick installs because it usually works out of the box, whereas Debian usually takes me days of tweaking to get it right.
In the past, before his old investigation image, and it’s replacement Buscador, I would build my own VMs based on either Debian or Xubuntu, and replicate the things he had done in his builds. This time around, I decided to build my own Xubuntu image, following his guide for the tools.
Here are the things I had to change to get Xubuntu based system set up.
I got an email saying that my site auto-upgraded. I wasn’t happy about it, some of the settings I on the server should have prevented that. But it did the auto-upgrade anyway.
When I logged in, the dashboard said to update to PHP I checked the terminal, since I’m self-hosting, and saw I had the newest available in the repo installed on the server. I had to do testing to find out, no it kept pulling the older version.
I searched around, and all the howto guides were for people using Cpanel or some other hosting tool. They also suggested the PHP text tool. Which I used, and it said all my plugins would work. But the howto guides for hosted accounts past that point wouldn’t work for me though. I’m self-hosted. I finally found a blog post by someone saying what to change, the webserver to point to the right files. So I did.
And the site broke.
The error wasn’t much help, but more searching found I could turn debug on get better information. So I did that. The page was tossing errors. Google those, and found a walkthrough to fix Crayon Syntax Highlighter.
I also had to toss Attack Scanner, which made me sad, but that plugin was shut down in 2017.
And I thought getting Let’s Encrypt fixed a couple of weeks ago was a pain.
Over the weekend I updated my mail server. Turns out if you have Dovecot installed and configured with Postfix, and Dovecot fails, Postfix stops working too. When I was trying to fix Dovecot I had mail in my mailbox, I could see it if I ran the mail command on the server. But I couldn’t see the email in my desktop client. After fixing Dovecot, I couldn’t see any new email in either place.
There was a poll on twitter recently asking about making a new blog. My suggestion was to self-host WordPress on a VPS, and then use the attacks against both as case studies for the blog itself.
The real question comes down to, “what is your goal?”
A couple of years ago, I don’t remember when, I built a small NAS using a Raspberry Pi 2 B version 1.1, and two 128G USB flash drives from Microcenter. It is called “raspi-nas”, and I built it following the How-To Geek Guide: How to Turn a Raspberry Pi into a Low-Power Network Storage Device. It worked well to back up our phones. Which is all it is used for. It used wireless for the network connection.
So as mentioned previously, I’m looking at using Python’s Virtual Environments, to keep code straight. Figuring out how to set it up was a bit of fun. I’m sure there are some great plugins for Atom, but I haven’t found them yet.
So far here is how I’m using it. I’ve created two directories, .venv and Projects. Both are in my home folder. When I create a new project directory, like AtBS_Udemy, I create a matching env directory under .venv. In AtBS’ case, it is AtBS_Udemy_env.
It’s actually working out pretty well so far, but I’ve only done this on 2 *Nix based boxes so far. A work VM and my travel-laptop. We’ll have to see how this goes long term.
I’ve been wanting to switch back to a Linux based system for a while. Main hold up has been school. Recently I got to rebuild my travel laptop to run Linux.
I started with Debian, but after 2 days and a bunch of tweaking of the system and still not to the point of of actually start working.
So out goes Debian, in moves Xubuntu. A couple of hours later up and running. Disappointed, I’d rather be running Debian. But I really don’t have the time to spend doing endless tweaking. I have several other things to do.
Bottom Line Up Front: Experienced Pytonistas say to use Virtual Environments. Very few say how in relation to your project, or where things should be stored. Store the project code outside the virtual environment folder.
Again going back to “Thoughts on Python”, one of the things that Wyatt suggested, was to use Virtual Environments for all my projects. When I started on rebuilding my page_watcher program, that watches parked domains for being moved to live sites, I thought hey why not.
Al Sweigart and Ryan Mitchell both mention using Virtual Environments in their books. But as far as I read in either, only as a passing mention with no in-depth information. Google shows there are a lot of tutorials online about using Virtual Environments, and I won’t re-hash those.
But things went sideways.
I had to install updates and new packages. So while I fighting with Ubuntu’s automated software updater getting in the way, and trying to install what I needed; I watched Corey Schafer’s Python Tutorial: virtualenv and why you should use virtual environments. Around the 8 minute and 30 seconds mark he points out that you shouldn’t use the virtualenv to hold your project code. But not where the project code should be stored.
I had already started to write the code in the Virtual Environment folder, from within the virtual environment. Only one of those two actions were right. So I had to stop and back out. But then the question came up, “where does one store project code wile using virtual environments?” Nothing I had came across really explained where to store the code. I tried asking on twitter but got no results. So, back to Google for more reading from links.
The two best blog posts I found that answered that was one by Vanessa Osuka at Code Like a Girl, A Guide to Virtual Environments in Python. and one just as good by Chris Warrick, Python Virtual Environments in Five Minutes. They both covered the same information. Ms. Osuka covered it a little earlier in her article, than Mr. Warrick did. But Mr. Warrick did so with a better example.
I’m still not sure how I’m going to set it up. Mainly because wrappers and not wanting to maintain multiple alias files (since I work on one of about 6 different computers / environments on any given project). But at least I know not to store the project in the virturalenv folder, and but instead in it’s own place (usually ~/bin/project_name).