Sunday, November 18 2007, 12:52 AM

A while back, I created a post on my successes with getting a workstation to boot off the network using an ATA over Ethernet (AoE) target as its root filesystem. My previous attempt required a good amount of manual intervention to get the initrd prepared. The boot process relied on gPXE to load the kernel and initrd from a TFTP server, which worked fine, but a downside of this approach is that I would need to make a new initrd and copy the new kernel over each time a new kernel package was released. With Fedora, the distro I'm using on my test machine, new kernels come out farily regularly.

While I was looking for some other piece of information, I stumbled across the means of telling gPXE how to boot directly from a AoE target without having to use TFTP to provide the kernel and initrd. This is desireable, since I wouldn't need to do any manual intervention when new kernel updates are released. This also allows for one to install an operating system that normally isn't network-boot-friendly, like Windows, on an AoE target. I'm not sure I would ever do that, but who knows. It might be fun.

The whole process was relatively straightforward, but I hit one major snag. The mkinitrd script that Red Hat provides doesn't have support for AoE, so I had to write a patch to provide that support. Once that patch was in place, I was able to generate AoE-friendly initrds, and booting the OS over the network became much easier.

I documented my procedure in a wiki article so others can try it. Some of it was taken from memory, so it may not be 100% complete. My next experiment is to see if I can get Fedora to do a native install onto an AoE target.

aoe linux wiki

Wednesday, February 14 2007, 12:38 AM

Tonight I discovered that MediaWiki has a RSS feed for the most recent changes to articles in the wiki. Knowing this, I decided to add another sidebar block for recent updates to the wiki. You may notice that there are currently duplicates. I guess that's how its designed. Instead of the last X pages that have been edited, ignoring when the edits take place, it shows the last 10 edits in order. Not a horrible thing really... and it still gets the message across.

I also added the little RSS buttons for direct links to the feeds that I use to generate the blocks, on the off chance that anybody cares to use them.

siteupdates wiki

Saturday, February 03 2007, 1:01 AM

As alluded to in my last post, I put up a wiki on the site. I've got a couple of articles up so far, mostly related to various scripts I've written. They're easy to cut and paste. I'll probably go back and edit a few posts to reference the wiki articles as they're written.

The link to the wiki is up in the menu bar. Wikitastic.

siteupdates wiki

Thursday, February 01 2007, 2:29 AM

I've been playing with Xen quite a bit over the past few weeks, and I must say that I'm becoming a fanboy. I've got it set up both on a machine home, and my colocated server at work. I am using it to break up my existing monolithic Gentoo server environments. I've got a couple main reasons for this.

First off, I'm just tired of having Gentoo in a server environment. It's pretty neat in theory, but in practice, its a beast to maintain. Compiling packages from source takes forever. Gentoo is very much bleeding edge, and because of that, things change often, and said changes aren't always painless. Binary distributions like CentOS definitely are at the opposite end of the spectrum. I've got a lot less free time these days to dink around with this and that, so I'll definitely take the ease of use of a binary distribution, and the relative stabiility in the software environment provided by an enterprise-level OS.

The second benefit to Xen is that I can use it to "disassemble" my current server installs one piece at a time instead of just migrating everything in one fell swoop. I've been slowly taking pieces of functionality out of main Gentoo environment and placing them into smaller single-purpose CentOS environments. This allows for the transition to be much easier, since testing one or two pieces of software at a time is much easier than ten or more. Currently I have separate environments for mysql, jabber, shoutcast, and a communal system logger along with the Gentoo environment I'm working to replace. Eventually, there will be environments for apache, DNS, and email services as well.

The third benefit is an added layer of security. With each service in its own Xen environment, the chances of the entire server being compromised via a single vulnerable service essentially goes away. It also allows for me to set up environments for family or friends without having to worry about them getting into things that they shouldn't be seeing.

Since Xen uses standard linux bridging to handle its internal networking, some pretty neat things are possible. I've got two network interfaces in my colocated box at work. One is connected to the internet, the other is connected to a private network. I only have the environments that require access to the internet connected to the public network bridge, but all of the environments are connected to the private network bridge interface. This allows all of the environments to communicate privately amongst themselves without the traffic ever leaving the physical server. As mentioned before, the second network interface is also connected to the private bridge, so I can (and do) connect other physical machines into the private network, and they see the Xen environments as if they were physical servers.

I was also able to do some more neat networking utilizing ssh and pppd. I found an article a few weeks back when I was looking into some ssh networking tricks, and it described a one-line command to create a ppp connection between two machines with ssh as its transport mechanism. This allowed me to create a tunnel that connected my home network to my private network inside (and outside) my colo box at work. The connection isn't very fast, but it's secure, and pretty stable. Its transparent to my machines at home since the tunnel is initiated by my gateway machine. The Xen environments only need a few static routes added for things to work properly, which is trivial. The only thing I'm doing with it so far is capturing usage statistics from all of the Xen environments via SNMP using Cacti. The slow speed of the tunnel doesn't affect that at all. I might try to set up mysql replication between my mysql environment in the colo box and the mysql environment at home for backup purposes. Who knows. There's a lot of possibility.

I'm thinking of setting up a personal wiki on the site here for various implementation notes, procedures, scripts, and other things. If/when I set that up, I'll post my notes on setting things up there.

Edit: I've documented the SSH PPP scripts in the wiki.

cacti networking pppd ssh wiki xen

Wednesday, November 02 2005, 12:41 AM

This has probably been done before, but I decided to set up a bash script tonight that would overload the ssh command and manage ssh connections using screen. I set it up so that when a detached screen to the host you're connecting to is present, it would reattach that screen session instead of making a new one. If there weren't any detached sessions, it starts up a new screen session by connecting to the host. I also made it name the screens in a somewhat intelligent manner. If the host you're connecting to is specified by an IP address, it'll attempt a reverse lookup to provide a more beneficial name than the IP. If the reverse lookup fails, it'll just use the IP. If you're connecting to a host based on a full or partial hostname, it'll just use that as the screen name. I also made another command to shortcut searching for screens - lsscr. If it's run with no parameters, it lists all screen sessions. If it is run with a parameter, it'll take that parameter as a search string and show screen sessions matching that search string. And since I dig open source, I post my work here for all to pilfer.

[EDITx2] I've updated the functions a few times, and instead of reformatting HTML each time, I'm just going to post it in the wiki. Enjoy. [/EDITx2]

This code should be placed in your user's .bashrc file (or the server-wide copy, if you prefer) for this to work right.

bash linux screen ssh tips wiki

Related Tags