A few months back I wrote an article on how to create and access an encrypted hard drive in Linux. Recently I've been setting up a large external usb drive to store nightly backups and couldn't figure out how to load the unencrypted device /dev/mapper/enc from the encrypted device /dev/sda1 post-boot (eg the usb drive wasn't turned on until the computer was completely started up). Lo and behold the answer was right in front of me, in my very own article, eg. step 3 or running the cryptsetup command:
cryptsetup -c aes-cbc-plain -d /etc/enc-key create enc /dev/sda1
I was under the impression that this altered the drive somehow, but does not in any way, it merely loads the unencrypted partition, from which point the user can mount the filesystem. I suppose a warning should go here, because I presume its possible (tho I have not tried it) to load the encrypted partition with a different key and thus the unencrypted partition will be "illegible", eg. the computer thinking its just random data. Any reads or writes to it will most certainly destroy any stored, encrypted information.
Anywho, it took me a little while to figure this one out, so I figure it might be useful for anyone else in the same situation.
1989 I started school at age 4
2008 I finished school at age 23
After 19 continuous years of school, I finished my last course today. No finals this semester (besides presentations I've given over the last week) so I'm finally finished, fulfilled all the requirements for a Masters Degree in Computer Engineering and don't have any more school. The years definitely have been full of both good classes and hard instructors, accomplishments and downfalls, projects which went off without a hitch and tests which were bombed horribly. I've met so many great people through my academic career and forged relationships which I hope never break. I'm not fully shutting the book just yet, I am floating the idea of a Ph.D. eventually, but a long break is long due. I'm sure I'll find plenty of things to pass the time with, I'm still working full time, and have a gazillion ideas concerning programming projects I want to do. In my personal life, my friend Louis started teaching me the guitar, and I'm looking at learning and doing all the things that I haven't had the time for yet (traveling is definitely in the picture). But anywho, this blog (which I'm finding to be alot more successful than any of my previous attempts, getting a bit of feedback from readers) will go on, so feel to check back!
Several years back, during my job at the Living School Book, I was tasked to admin a small LDAP server for a small project we were working on. It was all new too me at the time, and I took a while to learn it, writing up an article in the process. Lo and behold my time spent was worthwhile as I've been helping my current coworkers get up to speed on how LDAP works and is administrated. To help out, a former coworker (and good friend) helped me digg up this ancient article I wrote (alright only a few years old and everything is still relevant) on getting started with LDAP. Enjoy!
Essentially the goal for this article is to setup a partition under Linux under which all data that is stored will be encrypted and 'inaccessible' to those without the correct key (course with all the password-cracking software out there today, who knows what really is secure). This is actually a very simple task, with instructions scattered over the Internet, so I just simply consolidated the most useful directions I found into the guide below:
As a long time SVN user it is the version control system I know the best (though I am not a fan of any version control
implementations I've used so far, SVN is just the one I've used the most). I've never setup my own repository before and
looked into doing so today for various code of my own that I develop locally. All in all it is a simple process, but there are
a few gotchya's that you have to look out for.
Well in my first blog post since January 1st, I will be discussing and sumarizing what I learnt over the past few days relating to the GNU Autotools, specifically autoconf and automake. Having been a C++ fan since I learned it (roughly nine years ago, it was my first language), I never got around to learning the GNU build system (seeing as there is not much use in web development). Regardless, I set out to learn it as I need to incorporate it into my new currently-top-secret project. Note, I am writing this as I learn it and am no expert yet.
Theres alot of clutter out there when it comes to these, but to put it simply it all comes down to two files:
Lets work on making the world a better place this year
In my spare time over the last few months, I’ve been working on a project which I dub ‘Snap’. Snap is my attempt at replicating the functionality of ‘Windows System Restore’ on Linux. As the name indicates, Windows System Restore backs up all the important files, libraries, and registry entries on Windows for future restoration. To accomplish this in Linux, the underlying package management system is used. Snap stores which packages have been installed on the machine, and any files not tracked by the package management system or have been modified since installation.
Included is the Snap library, ‘snaptool’ the console frontend, and ‘gsnap’ the gnome gui. Currently only the Yum Package Management system is supported, but Snap supports a simple plugin interface, allowing easy support to work with any distro.
I hope people try it out and give me good feedback (patches are even better :-D), and I look to maintain it as much as I can in the future. I do have other things to work on (namely my master’s thesis which I have been pushing off till now) and since Snap already does what I need it to do (save my packages when upgrading between Fedora versions), I’m not sure how many new features I will add. But thats the beauty of open source, and I’m looking forward to anything anyone contributes
I am in the process of adding a gnome gui interface to my soon-to-be released project. Incorporating Python, GTK, and Glade, I’ve run into several quirky issues relating to running threads and sharing access to GTK widgets. Often I will see a worker thread hanging until the window is closed, at which point it resumes operation, or a more serious error:
Gtk-ERROR **: file gtktextlayout.c: line 1990 (gtk_text_layout_get_line_display): should not be reached
which indicates an illegal cross-thread boundary violation.
After much searching, I found this site which fills in the story concerning pyGTK and threading very nicely.
My current side project (to be announced/released soon) involves using the Yum Python API. Unfortunately I have yet to find a good tutorial or guide, though there are many apps which use the Yum API such as yumex, so I figure I'd share some knowledge about my findings. Note that I am using Yum version 3.2.7 and everything presented here is derived from my studying of the code.