It's been a while since I've posted anything and this might sound like a rant-post but I need to make a record of recent discoveries while it's still fresh in my mind.
As part of our annual update process I recently had to move 4 Slackware boxes from a KVM environment in a move towards setting them up as standalone Windows servers. The guy who previously looked after these was a devoted Slackware fan and probably has a dozen different Slackware machines at home now he's retired.
Now being the more cautious person in our team the thought struck me that it might be a good idea to have a backup of the htdocs directory from these four servers just in case there is anything on them which needs to be preserved. It surprised me how much of an issue this can be. First of all, it's easy enough to mount a USB stick and copy the files over from the command line but trying to then backup these to a Windows box caused all sorts of issues with unreadable files.
The next idea was to connect up a second drive for the data and boot from a Debian live (7) disk - the idea being that we can reverse this process quite easily to restore the files later if needed. The first problem here turned out to be that the data drive was already NTFS formatted. Debian would only mount this as read-only. I was further baffled by the new start-up menu's and then I discovered the second main problem - the apparent lack of the GFDisk partitioning tool. Even CFdisk seemed determined to only show the primary drive for some reason. The logical solution seemed to be to connect the data disk as the primary drive and install Debian to the drive (disconnecting the Slack drive in the process of course), then create some folders in the root for SERVER1, SERVER2... etc.
While the installation process was aesthetically pleasing with the blue install screens with a red progress bar, I was a little surprised at the end to reboot into x-windows and then discover that I can not log in as the root user (seriously?). Not a big problem as I also set-up a student account and I used that to log in. Then I discovered I could not create my SERVER1... etc folders in the root of the file-system. Well that's understandable as a student I suppose. Then I tried sudo mkdir only to be told that my student account was not allowed to use the sudo command and I would be reported to the administrator. At this point I'm thinking... "What? You're going to pester me every time a student tries to sudo?". While this is obviously the operating system behaving how it should in a big multi-user enterprise I began to question it's usability for our technically-savvy-just-about-sane-but-non-historical-unix-users group.
It was then that a little lightbulb (or LED) turned on somewhere (probably the Pi lab) and I started searching for my most recent Puppy linux disc. It booted up perfectly on all four servers, I could see which drives were connected, it let me mount them and create folders where I wanted to create them and it even copied the files faster than I had managed from the Slackware command line earlier. I could only fault Puppy on one very minor thing. The properties option on directories does not actually state the number of files they contain. This would have been useful as checking my folders showed some differences (1-2 Mb) on some of the directories. I put this down to transferring from Slackwares ext2 file-system to Debians ext4 but a file count would have just added a little more confidence in the copying process.
So while I may need to brush up on my Debian for our Pi students, I think I will keep my Puppy linux disc around for the important work; like restoring the servers after the new guy has installed Windows on them without checking if the data is important first. If this ever appears in a BOFH episode I want credit or a complimentary insulation-tester <Kzzzeerttttt!!>
