If you’re a sysadmin long enough, I guarantee one of your biggest pet peeves will be people telling you what command to run, rather than what their problem is. Trust me, suck it up. Be polite. Solve the problem the right way.
Below is an actual email I received from a technical recruiter. I’ve changed the company’s name to “ACME” to protect the innocent:
Subject: Nice profile!
After reading through your profile 3 times, I couldn’t help but reach out.
We’re ACME, a Los Angeles based tech company shaking things up in the Programmatic Advertising space.
We’re growing at 70% annually and have a new role for an Information Security Engineer. You’re probably not actively looking but so are 90% of the people I reach out to. But once they learn more about ACME, they’re very happy I reached out.
We have a pingpong table, pool table, foosball, and the people here are awesome. Dress code: ties and jackets are not allowed, shorts and flip flops are common.
Come see for yourself, you have nothing to lose and so much to gain. Can we talk?
If I was 30, and it was 1999, this job might have sounded interesting to me. But these days the last place I would want to work is a marketing company with a fraternity like atmosphere.
Rsnapshot is a simple but indispensable Open Source backup script that leverages the power of the rsync command (and SSH) to make backing up your Lunix/Unix infrastructure easy. It’s a must have tool in my opinion.
BTW, The best book for all things Unix/Linux Backup and Recovery (including Rsnapshot) is W. Curtis Preston’s Backup and Recovery from Orielly.
You can use Rsnapshot to write your backups to a second hard drive, an external USB or FireWire drive, an NFS mount from another computer on your network, or simply over the network to another computer via ssh.
Out of the box, the Synology DS1812+ comes with a powerful web-based user interface that makes setting things up easy. It does not support Rsnapshot be default. However, because the Synology NAS is itself it’s own little Linux machine (its OS is based on the BusyBox distribution), it’s possible to SSH into it to make your own customizations. The steps bellow will walk you through installing the “ipkg” package manager (simular to Yum on RedHat based distributions, or apt-get on Debian), as well as installing and configuring Rsnapshot.
Step one: Installing ipkg.
This first step is specific to the DS1812 and assumse you’ve already created at least one volume via the web-based admin interface. If you have a different model, see here for more details.
First thing to do is to enable SSH via the NAS’s web-based admin page. This is in the “Terminal” section of the Control Panel. Once enabled, SSH into your NAS with username “root” along with your admin password.
Next we want to download and install the ipkg bootstrap script. We first change directory to the “@tmp” directory of your first volume, download the ipkg bootstrap with the “wget” command, make the script executable, and then run the script…
chmod +x syno-i686-bootstrap_1.2-7_i686.xsh
After the script runs, you can delete it if you like. If your Synology NAS is using DSM 4.0 or newer you also have to edit /root/.profile and comment out the PATH and EXPORT statements at the top.
Now restart your NAS via the web-based admin page to finish the ipkg install. Once it’s rebooted, log back in as “root” via SSH.
Step 2: Installing Rsnapshot
Now that you have the ipkg package manager, installing rsnapshot (as well as many other Linux tools) is trivial… Along with Rsnapshot you will want to install “cron” in order to be able to automate/schedule backups. I also installed GNU screen, less, and mlocate to make life easier.
ipkg install rsnapshot
ipkg install cron
ipkg install less
ipkg install mlocate
ipkg install screen
There you go. The rsnapshot config file is located at /opt/etc/rsnapshot.conf
Note also that Cron on the Synology works differently than what you’re used to on most Linux distributions. For details on how to get cron working properly, see this thread on the Synology forums.
Some of the scientists I support at work rely on software that requires an old, defunct version of Ubuntu (6, Edgy). And because it’s starting to get hard to find hardware that will still run that old version of Linux I’m now using virtualization technology (KVM and CentOS 5.7). These instructions should work with Redhat and it’s derivatives.
The tricky part of all this (for me at least) was setting up the network. I need the virtual Ubuntu machine to appear on the network as if it were a separate host with a public IP, rather then behind a NAT router. Thus I used a bridged network setup. The method bellow worked for me, but it’s not necessarily the only or best way to accomplish this… I’ve tested these procedures on CentOS 5.7 and 6.2. Before we get started, you need to add two CentOS packages via the yum command: bridge-utils and tunctl.
Step One: Create a virtual network bridge (br0)
This particular server has one physical interface (eth0). What you have to do is create a virtual network bridge (br0), give it your public IP/GATEWAY/etc, and then add the physical interface to the bridge…
First, backup /etc/sysconfig/network-scripts/ifcfg-eth0 to another directory. My original ifcfg-eth0 looked like this
# Broadcom Corporation NetXtreme BCM5722 Gigabit Ethernet PCI Express
Now copy /etc/sysconfig/network-scripts/ifcfg-eth0 to /etc/sysconfig/network-scripts/ifcfg-br0. Edit the two files so that they look like so… notice that the IP and GATEWAY are now in ifcfg-br0 and not ifcfg-eth0.
/etc/sysconfig/network-scripts/ifcfg-br0 (I had do add my GATEWAY as well as copy over IPADDR)
Now reboot, or simply restart the network via the /etc/init.d/network script. If all is working properly, your host will still have a functioning network connection. You’re half way done…
Step two: Create a virtual, TUN/TAP interface (tap0) for your first VM.
To create the tap0 interface:
Bring up the new interface:
/sbin/ifconfig tap0 up
Now add tap0 to the bridge so it has access to your physical network:
/usr/sbin/brctl addif br0 tap0
Now, when you install or start your qemu vm, just make sure your “-net” option looks like the one bellow so that your vm has access to the tap0 interface. Most examples I’ve found on the net do these last steps in a script that then launches qemu…
/sbin/ifconfig tap0 up
/usr/sbin/brctl addif br0 tap0
qemu-system-x86_64 -hda disk.img -boot d -m 1024 -net nic -net tap,ifname=tap0,script=no -no-acpi
I have to admit that I found Cory Doctorow’s anti-iPad post at Boing Boing quite bizarre and techno-elitist. He seems to dislike both how easy the iPad is to use as well how efficiently it’s physical parts are put together (glue as opposed to screws).
His argument that the iPad is “Infantalizing [sic] hardware” is particularly short-sighted. I view the iPad as a sort of satellite of my main workstation. With such a device, good user interface design should free the user from the sort of things that make a full blown computer more cumbersome, albeit more powerful. When you’re relaxing on the couch with a cup of coffee, or on a road trip to San Fran, and all you want to do is read Wikipedia, peruse your comic library, or catch up on the latest news, your iPad is probably a good delivery method.
Furthermore, what’s more important? Simple and easy-to-use access to the world’s information database, or you’re ability to disassemble the device your using to read it? The answer is obvious. The benefits of miniaturized (system on a chip) ICs, vertical circuit fabrication, and the power efficiency they bring far, far outweigh the the benefits of being able to disassemble such a device. And I would argue that the physical device itself is far less important in the grand scheme of things compared to the almost infinite software possibilities.
And of course, as a professional Unix admin, I know that options exists for people who want to tinker at a very low level (Linux + cheap commodity hardware). We shouldn’t think of the iPad as a replacement, but rather just another option.
OpenAFS is an open source implementation of AFS that works nicely with JPL’s setup. It’s easy to install and quite stable.
I’ve tested these instructions in 9.04, 8.10, and even recently in 6.06 (Yes, the apt-get method of maintaining a Linux machine is far superior to using RPMs).
The first step is to build and install the OpenAFS kernel module. The following steps take care of downloading the appropriate software, compiling and installing everything. As usual, this needs to be done as root, or using the sudo command.
$ apt-get install module-assistant openafs-modules-source
$ module-assistant prepare
$ module-assistant auto-install openafs-modules
$ depmod -a
If all of that is successful, your computer should now have the OpenAFS kernel module buit and installed. The next step is to install the OpenAFS client software.
$ apt-get install openafs-client openafs-krb5
Ok, you now have all the software you should need. The last step on Ubuntu systems is to configure OpenAFS per your site. Running the following command will start an interactive program that asks you about your site specific AFS configuration. The most important piece of info you’ll need is your “Cell” name. For us at JPL, it’s jpl.nasa.gov. I’ve found that most of the time, the default responses for the rest of the questions are fine.
$ dpkg-reconfigure openafs-client
Installing on Fedora / CentOS / Red Hat:
Unfortunately, installing OpenAFS requires a few more steps on RPM based distributions, but nothing too tough. Mostly, this involves hunting down the appropriate RPMs for your system. I’m using CentOS for this example. For those not in the know, CentOS is basically a free, binary compatible version of RedHat Enterprise Linux. Please visit CentOS.org for more details.
First, you’ll need to locate the appropriate RPMs for your distribution and kernel version. The following RPMs were required on my CentOS 5.3 machines:
$ rpm -qa | grep afs
You can find these RPMs in a few places as none of these distributions provide them for you. First off, ATrpms has them. In the past, I’ve also found them at the main OpenAFS site, OpenAFS.org. Pbone, another third party RPM repository, has OpenAFS rpms that where built for Redhat EL5 here. Those RPMs will work just fine with CentOS 5 too. Lastly, another place to get hard to find RPMs is RPMforge.
Once you have your RPMs installed, then you only have to edit one config file. Populate /etc/openafs/ThisCell with your sites specific cell name. Some smaller sites will have to configure /etc/openafs/CellServDB as well.
Thats it. You should be able to start the OpenAfs daemon (/etc/init.d/openafs start) and then start using AFS.