Wednesday, February 9, 2011
PC Pro Magazine runs an Ubuntu cover story, and goes Ubuntu for the day
For the first time in 17 years, PC Pro magazine will be running a Linux cover story.
Even more impressive than that, the company itself will migrate all of its web servers and employees over to Ubuntu Servers and Desktops for the day!
More info here:
http://www.pcpro.co.uk/blogs/2011/02/09/can-we-run-pc-pro-on-ubuntu/
And you can follow the #ubuntupro Twitter feed. I'm quite intrigued!
:-Dustin
Even more impressive than that, the company itself will migrate all of its web servers and employees over to Ubuntu Servers and Desktops for the day!
More info here:
http://www.pcpro.co.uk/blogs/2011/02/09/can-we-run-pc-pro-on-ubuntu/
And you can follow the #ubuntupro Twitter feed. I'm quite intrigued!
:-Dustin
Monday, February 7, 2011
Update on errno, ssh-import-id, and bikeshed
If you read my post from earlier today about run-one, you might notice that I used a new source and binary package to publish the run-one utility. This is a new practice that I'm going to use for stand-alone tools like this.
errno
It's worth mentioning that the errno utility has also moved out of ubuntu-dev-tools, at the strong request of the maintainer of ubuntu-dev-tools. I tried (in vain) to get errno into various other packages and upstream projects, and failed in all cases. As of Natty, you can:
For older releases:
As a reminder, you can use errno in these ways:
$ errno font
EBFONT 59 /* Bad font file format */
$ errno 36
ENAMETOOLONG 36 /* File name too long */
$ errno EPERM
EPERM 1 /* Operation not permitted */
You can find the sources with:
And the launchpad project is at http://launchpad.net/errno.
ssh-import-id
Similarly, the maintainer of the openssh package in Ubuntu urged the removal of the ssh-import-id utility. Once again, I offered the tool to the upstream openssh project, to no avail. So ssh-import-id now lives in its own source and binary packages. As of Natty, you can:
For older releases:
As a reminder, you can use ssh-import-id in this way:
You can find sources with:
And the launchpad project is at http://launchpad.net/ssh-import-id.
bikeshed
"So why didn't you just use bikeshed?" Great question! When I showed run-one to one of my colleagues, he said, "Neat, I'd use that, where can I get it?" And I pointed him to install bikeshed, to which he responded, "Oh, well, I just want run-one, but not all the other cruft you put into bikeshed." :-)
I tried not to be offended, but in the end, he was right. I thought about splitting bikeshed into a series of bikeshed-$FOO binary packages. This wasn't ideal, though, in my opinion, from the perspective of developing code or handling bugs/questions.
Thus, I've decided to create a new Launchpad project and team, and Ubuntu package for each of these stand-alone utilities.
I'll continue to use bikeshed to incubate new tools, and as soon as they're ready to stand alone, then I'll split them out to their own branch/project/team/package.
Cheers,
:-Dustin
errno
It's worth mentioning that the errno utility has also moved out of ubuntu-dev-tools, at the strong request of the maintainer of ubuntu-dev-tools. I tried (in vain) to get errno into various other packages and upstream projects, and failed in all cases. As of Natty, you can:
apt-get install errno
For older releases:
sudo apt-add-repository ppa:errno/ppa
sudo apt-get update
sudo apt-get install errnoAs a reminder, you can use errno in these ways:
$ errno font
EBFONT 59 /* Bad font file format */
$ errno 36
ENAMETOOLONG 36 /* File name too long */
$ errno EPERM
EPERM 1 /* Operation not permitted */
You can find the sources with:
bzr branch lp:errno
And the launchpad project is at http://launchpad.net/errno.
ssh-import-id
Similarly, the maintainer of the openssh package in Ubuntu urged the removal of the ssh-import-id utility. Once again, I offered the tool to the upstream openssh project, to no avail. So ssh-import-id now lives in its own source and binary packages. As of Natty, you can:
apt-get install ssh-import-id
For older releases:
sudo apt-add-repository ppa:ssh-import-id/ppa
sudo apt-get update
sudo apt-get install ssh-import-idAs a reminder, you can use ssh-import-id in this way:
$ ssh-import-id kirkland smoser
INFO: Successfully authorized [kirkland]
INFO: Successfully authorized [smoser]
INFO: Successfully authorized [kirkland]
INFO: Successfully authorized [smoser]
You can find sources with:
bzr branch lp:ssh-import-id
And the launchpad project is at http://launchpad.net/ssh-import-id.
bikeshed
"So why didn't you just use bikeshed?" Great question! When I showed run-one to one of my colleagues, he said, "Neat, I'd use that, where can I get it?" And I pointed him to install bikeshed, to which he responded, "Oh, well, I just want run-one, but not all the other cruft you put into bikeshed." :-)
I tried not to be offended, but in the end, he was right. I thought about splitting bikeshed into a series of bikeshed-$FOO binary packages. This wasn't ideal, though, in my opinion, from the perspective of developing code or handling bugs/questions.
Thus, I've decided to create a new Launchpad project and team, and Ubuntu package for each of these stand-alone utilities.
I'll continue to use bikeshed to incubate new tools, and as soon as they're ready to stand alone, then I'll split them out to their own branch/project/team/package.
Cheers,
:-Dustin
Labels:
Bikeshed,
Canonical,
run-one,
ssh-import-id,
Ubuntu,
Ubuntu-Server
Sunday, February 6, 2011
Introducing: run-one and run-this-one
I love cronjobs! They wake me up in the morning, fetch my mail, backup my data, sync my mirrors, update my systems, check the health of my hardware and RAIDs, transcode my MythTV recordings, and so many other things...
The robotic precision of cron ensures that each subsequent job runs, on time, every time.
But cron doesn't check that the previous execution of that same job completed first -- and that can cause big trouble.
This often happens to me when I'm traveling and my backup cronjob fires while I'm on a slow up-link. It's bad news when an hourly rsync takes longer than an hour to run, and my system heads down a nasty spiral, soon seeing 2 or 3 or 10 rsync's all running simultaneously. Dang.
For this reason, I found myself putting almost all of my cronjobs in a wrapper script, managing and respecting a pid file lock according to the typical UNIX sysvinit daemon method. Unfortunately, this led to extensively duplicated lock handling code spread across my multiple workstations and servers.
I'm proud to say, however, that I have now solved this problem on all of my servers, at least for myself, and perhaps for you too!
In Ubuntu 11.04 (Natty), you can now find a pair of utilities in the run-one package: run-one and run-this-one.
run-one
You can simply prepend the run-one utility on the beginning of any command (just like time or sudo). The tool will calculate the md5sum $HASH of the rest of $0 and $@ (the command and its arguments), and then try to obtain a lock on a file in $HOME/.cache/$HASH using flock. If it can obtain the lock, then your command is simply executed, releasing the lock when done. And if not, then another copy of your command is already running, and it quietly exits non-zero.
I can now be safely assured that there will only ever be one copy of this cronjob running on my local system as $USER at a time:
If a copy is already running, subsequent calls of the same invocation will quietly exit non-zero.
run-this-one
run-this-one is a slightly more forceful take on the same idea. Using pgrep, it finds any matching invocations owned by the user in the process table and kills those first, then continues, behaving just as run-one (establishing the lock and executing your command).
I rely on a handful of ssh tunnels and proxies, but I often suspend and resume my laptop many times a day, which can cause those ssh connections to go stale and hang around for a while before the connection times out. For these, I want to kill any old instances of the invocation, and then start a fresh one.
I now use this code snippet in a wrapper script to establish my ssh socks proxy, and a pair of local port forwarding tunnels for (squid and bip proxies):
Have you struggled with this before? Do you have a more elegant solution? Would you use run-one and/or run-this-one to solve a similar problem?
You can find the code in Launchpad/bzr here, and packages for Lucid, Maverick, and Natty in a PPA here.
Cheers,
:-Dustin
The robotic precision of cron ensures that each subsequent job runs, on time, every time.
But cron doesn't check that the previous execution of that same job completed first -- and that can cause big trouble.
This often happens to me when I'm traveling and my backup cronjob fires while I'm on a slow up-link. It's bad news when an hourly rsync takes longer than an hour to run, and my system heads down a nasty spiral, soon seeing 2 or 3 or 10 rsync's all running simultaneously. Dang.
For this reason, I found myself putting almost all of my cronjobs in a wrapper script, managing and respecting a pid file lock according to the typical UNIX sysvinit daemon method. Unfortunately, this led to extensively duplicated lock handling code spread across my multiple workstations and servers.
I'm proud to say, however, that I have now solved this problem on all of my servers, at least for myself, and perhaps for you too!
In Ubuntu 11.04 (Natty), you can now find a pair of utilities in the run-one package: run-one and run-this-one.
run-one
You can simply prepend the run-one utility on the beginning of any command (just like time or sudo). The tool will calculate the md5sum $HASH of the rest of $0 and $@ (the command and its arguments), and then try to obtain a lock on a file in $HOME/.cache/$HASH using flock. If it can obtain the lock, then your command is simply executed, releasing the lock when done. And if not, then another copy of your command is already running, and it quietly exits non-zero.
I can now be safely assured that there will only ever be one copy of this cronjob running on my local system as $USER at a time:
*/60 * * * * run-one rsync -azP $HOME example.com:/srv/backup
If a copy is already running, subsequent calls of the same invocation will quietly exit non-zero.
run-this-one
run-this-one is a slightly more forceful take on the same idea. Using pgrep, it finds any matching invocations owned by the user in the process table and kills those first, then continues, behaving just as run-one (establishing the lock and executing your command).
I rely on a handful of ssh tunnels and proxies, but I often suspend and resume my laptop many times a day, which can cause those ssh connections to go stale and hang around for a while before the connection times out. For these, I want to kill any old instances of the invocation, and then start a fresh one.
I now use this code snippet in a wrapper script to establish my ssh socks proxy, and a pair of local port forwarding tunnels for (squid and bip proxies):
run-this-one ssh -N -C -D 1080 -L 3128:localhost:3128 \
-L 7778:localhost:7778 example.com
Have you struggled with this before? Do you have a more elegant solution? Would you use run-one and/or run-this-one to solve a similar problem?
You can find the code in Launchpad/bzr here, and packages for Lucid, Maverick, and Natty in a PPA here.
bzr branch lp:run-one
sudo apt-add-repository ppa:run-one/ppa
sudo apt-get update
sudo apt-get install run-oneCheers,
:-Dustin
Labels:
Canonical,
run-one,
Ubuntu,
Ubuntu-Server
Tuesday, January 18, 2011
Ubuntu Server Survey 2011
Take advantage of your voice in the direction of the Ubuntu Server!
We invite your comments and opinions in the 2011 edition of the Ubuntu Server Survey. What do you need from your Linux servers? What are your preferred management tools? Favorite storage solutions? What else do you want out of your Linux servers?
http://survey.ubuntu.com/
Cheers,
:-Dustin
We invite your comments and opinions in the 2011 edition of the Ubuntu Server Survey. What do you need from your Linux servers? What are your preferred management tools? Favorite storage solutions? What else do you want out of your Linux servers?
http://survey.ubuntu.com/
Cheers,
:-Dustin
Thursday, January 13, 2011
Working toward Ubuntu 11.04 Server
Ahmed Kamal and I had a discussion on camera here at the Ubuntu Developer Rally in Dallas, Texas. We talked a bit about the Ubuntu Server's road map this development cycle toward the upcoming Ubuntu 11.04 release in April 2011. It was a nice opportunity halfway through the Natty development cycle to take a step back and see what we've accomplished, and what we're still working on for the current release. Enjoy!
:-Dustin
:-Dustin
Wednesday, January 5, 2011
SCALE9x - Byobu: GNU Screen for Human Beings
I'm quite pleased that my presentation proposal has been accepted to the SCALE9x conference, to be held February 25 - 27, 2011 in Los Angeles, CA. I hope you'll join me for...
Category: Developers Track, Technology
Audience: Advanced, Intermediate, Beginner, Everyone
Abstract:
UNIX and Linux system administrators have been blessed with the GNU Screen utility for almost 25 years. Expert Screen users will swear by its importance in their toolbox. But the learning curve for new users getting started can be quite steep.
Enter 'Byobu', an innovative, intuitive approach to GNU Screen, brought to you by the Ubuntu Server community. Byobu is a set of wrapper scripts and configuration settings that unleash the power of GNU Screen for beginner and novice system administrators, while continuing to support Screen's advanced features for expert users.
Byobu includes convenient keybindings, useful status scripts, sensible configuration defaults, and a curses-based utility for modifying some of Screen's most important (but most buried) features.
In this presentation, the author of Byobu will introduce the basic flow of operation, and move into the advanced features of Byobu and GNU Screen. Any Linux user attending this presentation will be more productive when interfacing with their command line hereafter...
:-Dustin
Labels:
Byobu,
Canonical,
conferences,
Ubuntu,
Ubuntu-Server
Monday, January 3, 2011
New RSA 4096 GPG Key
Welcome to 2011!
I'm ringing in the new year by transitioning to a new, stronger GPG key (F1529469). I followed the excellent instructions from the Ubuntu Security Team (thanks guys!) and the process has been relatively painless.
If you’ve signed my old key (83A61194), I’d appreciate it if you could review my signed transition statement and sign my new key too.
Thanks!
:-Dustin
Subscribe to:
Posts (Atom)




