Open Source News

I’ve probably said it before, and will say it again, and I’m also sure that I’m not the first, or the last to make this point, but I have yet to see an example of an open source design process that has worked.

Indeed, I’d go so far as to wager that “open source design” is an oxymoron. Design is far too personal, and too subjective, to be given over to the whims and outrageous fancies of anyone with eyeballs in their head.

Call me elitist in this one aspect, but with all due respect to code artistes, it’s quite clear whether a function computes or not; the same quantifiable measures simply do not exist for design and that critical lack of objective review means that design is a form of Art, and its execution should be treated as such.

Trunk › Dashboard — WordPressWhat’s got my panties in a bunch? Well, this screenshot depicts the new WordPress Admin Dashboard coming in the forthcoming release, version 2.4, which you can check out from the WordPress SVN repository. From Mr Mullenweg’s own admission, it’s only about 10-20% complete, but you wouldn’t know that from the feedback this work-in-progress is already generating.

Coming from CivicSpace, where we had a beautiful website before we had working code, to working on Flock, where the mockups never quite matched the software that was released, I feel like I’ve seen enough of these fruitless cycles to take for granted that design and open source development are simply incompatible, or, to be clear: the expectations that one has with open source software development cannot be the same expectations that one has for open source interface/interaction design.

From my experience, what can I say about constructive open source UI/UX design?

1. Set expectations. As a designer, I’m trained to take feedback and to accept as given that people will shred my work in the interest of improving it. But I also know that there are plenty of folks who do care but simply don’t know how to provide useful feedback. It’s my job to make it clear what kind of feedback I’m looking for and what feedback I don’t need. It’s also up to me to communicate that I reserve the right to reject any feedback given. It’s up to the feedback-giver to not take it personally.
2. Set deadlines. This one follows the previous point, but if you’re doing any kind of design review, it’s pretty important to put some temporal boundaries on how long the window is open to be given feedback and how long it will likely take to implement it. Nothing’s worse than unrequited design feedback, even if it’s feedback that isn’t useful.
3. Know where you’re at. My more naive self would rebel against what I’m about to propose, but there’s no way around it. If you’re acting as a designer, it’s up to you to “own” the design process and to only ask for feedback when you’re clear on the kind of feedback you’re looking for. Open source shouldn’t be about ultimate compromise or mamby-pamby democratic ideals where everyone has a say. Curiosity kills plenty of cats, but consensus is goddamn plague on most projects so get it in your head that open source is about public demonstrations of repeated meritocratic value creation and not about listening to every Tom, Dick and Harry that has something to spew. And anyone who hasn’t proven themselves by previously being raked over the coals of public criticism and critique should be treated accordingly. Remember, opinions are like assholes and vegetarians are still in the minority.
4. Use productive and appropriate tools. The most aggravating aspect of participating in the Mozilla community has been their reliance on Bugzilla, one of the worst possible tools for design review and discussion. Can you believe that they still do design in ASCII art? Me neither. Look, when you’re doing interactive design, you should try to get as close as possible to the target environment as possible when working and designing. Can you remember the last time you used an application whose interface was made of pipes, ellipses and clever uses of brackets? Neither can I. Therefore interfaces should be presented using tools that support constructive dialogue and feedback. Flickr is actually a great tool for this purpose, with its Notes feature. ConceptShare is another one, developed specifically with this use case in mind. More and more Skitch and Jing are other tools that serve this purpose, as are screen capture applications like iShowU and even Leopard’s built-in Screen Sharing application.
5. Be clear about the problem you’re solving. Nothing spells disaster for a design process more than fishtailing. If you don’t know what problems you’re trying to solve and you don’t have razor-sharp focus on it, chances are you’ll be open to whatever feedback you can get your hands on, grasping for some notion of what the hell you should be working on. This is not design, this is horseshoes and hand grenades.

Look, it’s okay to not have everything figured out when you embark on a project, and it’s even okay to admit that and to embrace it. It’s wholly another thing to pretend to know what you’re doing and then go about asking for feedback. By its design and nature feedback is intended to raise deltas between the perceived reality and the potential reality. For feedback to be useful and productive, you, as the designer, have to stayed trained on the ultimate endpoint that you’re driving towards and systematically exhaust all possible combinations presented by the feedback that will lead you to non-ideal solutions. This is how you use feedback to whittle away at an opportunity until you finally arrive at a satisfying outcome.

To put it another way, existential deviation on a theme is certainly okay and to be encouraged; experimentation is where a lot creative ideas will come from. But in the context open source feedback flows, this is absolutely NOT where you want to fluctuate. Trust me, this is where design hijack takes over, and where you’ll lose your control and leverage over the direction of a project. If you hold the reigns tight, an open feedback process can be extremely rewarding; let slip and you’re likely to be overwhelmed in a sea of confusing and confounding false opportunities.
6. Be focused. This tip is twofold and builds on the last. You should be focused on the feedback you need, and rather than going for blanket advice, narrow in on specific user flows or tasks. On top of that, the less certain you are about the approach you want to take or about the appropriate solution to pursue, the smaller the pool of respondents you should consult should be. This is what I mean by “be focused”: the more uncertainly in the project, the fewer external voices you should consult, especially en masse; the further along in the project you are, and the more certainty you have, the more you can open it up for general feedback. Note too that people will bring their own preferences, assumptions and beliefs with them, so choose your early critics wisely.
7. Care deeply and sacrifice nothing. This one’s probably the hardest of all, and really can only be learned/earned over time. The role of the designer is, against all odds, to synthesize and to make sense of ambiguous circumstances, poor or changing problem descriptions, to weigh the individual needs of project sponsors, of product users, or subjective tastes and of sating the hunger of one’s own ego to produce something better than you thought yourself capable of. And it’s nearly impossible to fake it. But the best approach seems to be to do your homework and care deeply about the work that you’re doing and to identify with the problem that you’re trying to solve. Sacrifice nothing in the way of arriving at a solution that meets your highest personal criteria. It helps when you’re your own worst (best) critic, but it’s all the more essential when you’re putting yourself out there for public scrutiny. If you know that you’re not going to let yourself get away with anything, you should be able to face whatever slings and arrows the outside world will heave your way, all as part of.

And so we return to the case of the WordPress 2.4 Admin Dashboard. It’s unclear who owns this project or the feedback coming in (I don’t remember seeing a public call for comments, so this must just be unsolicited feedback), but I sure as heck hope that whoever it is takes this current round of feedback with less than a grain of salt. As far as I’m concerned (and as much as I’d like to affect the design process myself) WordPress deserves more time to make its case for the new design, and to implement closer to 70-80% of the design before people start pontificating about how things should be different (or remain the same) (not like any such plea will stem the onslaught).

With open source development, the cat is always out of the bag. As such, it keeps you honest and focused on issues that people care about, even if they’re occasionally peripheral to the main issues you set out to solve.

So the problem with open source design is not the feedback (designers et al should be grateful when it comes) but with the ego issues that are wrapped up in how feedback is delivered and how it’s received. And these are ultimately social issues. The points I outlined above have as much to do with clear communication, acknowledgement and a Buddhist-esque equanimity as with any kind of formal design training. If open source design is to advance, and to become a dominant force in the creation of exquisite software experiences and interfaces, I say we start here.

Every sysadmin will try its best to secure the system/s he is managing. Hopefully you never had to restore your own system from a compromise and you will not have to do this in the future. Working on several projects to restore a compromised Linux system for various clients, I have developed a set of rules that others might find useful in similar situations. The type of hacks encountered can be very variate and you might see very different ones than the one I will present, or I have seen live, but even so, this rules might be used as a starting point to develop your own recovery plan.

In most cases if you have a system compromise at root level, you will hear that you have to fully reinstall the system and start fresh because it will be very hard to remove all the hidden files the attacker has placed on the system. This is completely true and if you can afford to do this then you should do it. Still even in this case the compromised system contains valuable information that can be used to understand the attack and prevent it in the future.

Here is a short overview of the steps that I will present:

• Don’t panic. Keep your calm and develop a plan of actions
• Disconnect the system from the network
• Discover the method used to compromise the system
• Stop all the attacker scripts and remove his files
• Restore not affected services
• Fix the problem that caused the compromise
• Restore the affected services
• Monitor the system

Don’t panic. Keep your calm and develop a plan of actions

Ok. You have just found out that you have to restore a hacked system. My first suggestion is to remain calm. Don’t rush and do something you will regret later. Why? Of course you will have to take action as soon as possible, but you can assume that the compromise is probably active for some time and if you act in second 1 or minute 10 this will probably not make much of a difference. If you have experience with such situations and have a proper plan in your mind, go for it, and don’t waste any time. If not, just relax, take 5 minutes to think about what you should do and how to solve this problem.
Example of bad actions during this time: you will rush and kill all the running scripts the attacker has launched and then have a timeout when you will think what to do next… In this time the attacker might see you have discovered him (for example from his irc bot, etc.) and might become upset and clean up the system for you…
Of course you should not go on with your planned trip and take care of this when you get back, I am just saying to use 5-10 minutes to think on this and develop a short action plan. There should be no timeout in your actions and you should always know what is the next step.

Disconnect the system from the network

This might not always be possible. But if you have physical access to the system or even if you are remotely on a system in a datacenter that provides a way to connect from a console (either a regular remote console, or a KVM, or a DRAC card in Dell servers, etc.), then this should be the next step. Connect to the remote console and bring down the network interface.
If you don’t have a remote console, here are some other ideas: you might be able to rent a KVM for a limited time from your datacenter, or you might have to write some iptables rules to block any kind of access besides your own IP.
After this your system will appear down to everyone, including the attacker that will see that the system is completely down.

Discover the method used to compromise the system

This step in my opinion is the most important one and you should not proceed any further until you have a proper answer to the question: “How did the attacker get in?” This step will be probably the most time consuming as the type of attacks can be quite variate. Still if you don’t find out how the attacker got in, then you will risk that you place the system online and he will be able to compromise the system in a matter of minutes. And this time he might not be so nice and you will not have anything to restore… So even if there is not a general method for this, here are some ideas to get you started:

Depending from what tools you have already configured, you need to identify the files uploaded on the system:

• if you have a system like tripwire configured use it to find out what files where added/changed.
• if you don’t have any such system installed, you might have to use the find command to search for the files newer than x days that were added to the system (also changed files in the respective interval).

Who owns the uploaded files?

• finding out the owner of the files will probably show you what application was used to get in. For example files uploaded as the web user will indicate that the web service was used to get in.

Investigate the uploaded files.

• the files that were uploaded on the system might provide valuable information about the attack. For example the attacker might use the same exploit to attack other systems from your compromised server. This can quickly show you what exploit he is using.

Get as much information from the running scripts launched by the attacker.

• as you have seen I have not recommended to stop yet the running scripts that the attacker might have launched. Why? Because they contain invaluable information to identify the attack. Use lsof on them (lsof -p PID) to see useful details. Where are they located? what user owns them? You might find the source of the attack from this information.

Use Rootkit detection tools.

• you might want to run some rootkit detections tools like rkhunter or chkrootkit to quickly identify common attacks.

Investigate system logs.

• with the information gathered by now you might reduce the size of the log information you have to investigate.

Hopefully you have found the source of the attack by now. Again this is very dependent of the type of attack. The most common one you might see these days is an exploit using a vulnerable web application and an attacker that will launch various scripts (irc bots, scanning tools, attacks on other systems, etc.). Still you might see something different like an attacker not launching any script, loading kernel modules to hide its tracks, to make it more difficult to identify or even see the compromise.

Stop all the attacker scripts and remove his files

Once you have identified the cause of the attack you can safely kill all the running scripts launched by the attacker and remove all his files (save them in a different location for further investigation). At this point we no longer need the scripts running as we got the information we could find from them. The system is still unavailable at this point and no service is available to the world.

Don’t forget to clean-up also the locations that the attacker might have entered to start his scripts on system reboot. Look in init scripts, rc.local, cron tabs for this.

Restore not affected services

Once we know the service used for the attack we can stop it and restore the network connection and all the unaffected services the system might provide. For example if the web server was used to get in, we can stop it, and restore other services like mail, dns, to minimize the downtime of the system.

Fix the problem that caused the compromise

Before starting the service used to compromise the system you should fix the problem so this will not happen again once the service is open to the public… Depending on the problem this might involve: patching a vulnerable daemon, upgrading a vulnerable web application (or temporary disable it), writing some special rulers to block it (for ex. mod_security rules might help in case of no patch available for a web application), etc.

Restore the affected services

Once you have fixed the problem you can restart the service used to get inside the system.

Monitor the system

Now is the time to monitor closely the system and see if the fix you have implemented is working. Most certainly the attacker will try to get in again as he will see he has ‘lost’ the system. If you notice any problem stop the service at once and reiterate again to the step to fix the problem (stop the service, fix it, restore it).

Conclusion

These steps are obviously not usable all the time because of the variety of attacks you might encounter, but they can be used as a baseline to develop your own plan of actions. Again in such situations, keep your calm, don’t rush, and work to restore the system based on a clear set of steps.
If you had similar experiences please feel free to share your own tips to help others that might find themselves in such a situation.

This article will explain how you can install the latest memcached daemon (including the libevent library) on a linux system. The only prerequisite for memcached is libevent so we will have to install this first.

Note: the output of the commands in this article are taken from a Debian Etch system. They should work on any recent linux distribution, but depending from your version you might need to make some changes. The versions of memcached and libevent used in this article are the latest stable one existing at the time this was written. Check the download pages bellow, and if newer versions exists you will probably want to use them.

Install Libevent 1.3e

I will assume that you don’t have libevent installed already on your system. Your system might already have libevent installed, but normally you will have a very old version (for ex. on debian etch the packaged libevent is 1.1a that was released in 2005); in this case you will want to remove the system package first (for ex. on debian run: aptitude purge libevent1). If you have a recent version packaged by your linux distribution you should keep it and move on the next step to install directly memcached.

Download, and install the latest version of libevent (check for the latest version, and change if needed the versions bellow):
cd /usr/local/src
wget http://monkey.org/~provos/libevent-1.3e.tar.gz
cd libevent-1.3e
./configure
make
make install

This will install by default the libraries under /usr/local/lib/. If you want it in another place you can do that by passing to configure a different prefix.

Depending on your system you might have already /usr/local/lib included in your ld configuration. If this is not the case (like on my test debian box) you can add it inside /etc/ld.so.conf, or as a nice debian “thing†you can just create a new file inside /etc/ld.so.conf.d/ like:

vim /etc/ld.so.conf.d/libevent.conf
##add a line containing:
/usr/local/lib/

Regardless of your choice you should run ldconfig to complete this step:
ldconfig -v
(and check the output to be sure that the /usr/local/lib has been properly included).

Install Memcached 1.2.4

After we have libevent properly installed on the system we can proceed and install memcached. Download the latest stable version and install it using the following steps:

cd /usr/local/src
wget http://danga.com/memcached/dist/memcached-1.2.4.tar.gz
tar zxvf memcached-1.2.4.tar.gz
cd memcached-1.2.4
./configure
make
make install

The memcached binary will be also installed by default under /usr/local/bin/. You can start the daemon by simply running: /usr/local/bin/memcached. The basic memcached options are:
memcached -d [-m memory_in_megabytes [-l listen_ip_address [-p listen_port]]]
For ex:
memcached -d -m 256 -u nobody -p 11211 -l 192.168.0.1
will be used to run a memcached daemon bind on 192.168.0.1 on the default port 11211 using max 256MB memory.

This document describes how to install and use sshfs, a FUSE based filesystem that uses SSH to mount remote folders. Since it is based on FUSE (userspace filesystem framework for Linux) your kernel will need to have the fuse module available. FUSE is included in kernel newer than 2.6.14, so I will assume that you will have it already included in your kernel.

Fuse is included in the stock debian etch kernel (2.6.18) but if you install this on a older debian system you could easily use module-assistant to add FUSE support to your kernel:
apt-get install kernel-headers-`uname -r` fuse-source module-assistant
module-assistant clean fuse
module-assistant build fuse
module-assistant install fuse

Installing sshfs

The only thing left is to install sshfs. In debian etch this is as simple as:
aptitude install sshfs
This will install also the required dependencies: fuse-utils, libfuse2

Now, we should be able to use sshfs, and we can try to mount a remote server’s /data folder with:
sshfs 192.168.0.1:/data ~/mnt
(depending how you connect to the remote ssh server, this will ask you for a user or key password, etc.). You will need to have proper permissions. If you require you can also use -o idmap=user to translate the remote ssh user to the local user specified in the command.

Troubleshooting

If you get this error:
fusermount: failed to open /dev/fuse: No such file or directory
fuse_mount failed.
this means that even if your kernel uses udev to dynamically create devices, in this case it has not done that. The solution for this is to load first the fuse kernel module. This will take care and create the device /dev/fuse:
modprobe fuse
This will work until the first reboot, and if you want to make this change permanent you will have to add the fuse module to the automatically loaded module list. For ex. in debian you would add to your /etc/modules a line containing the word “fuse†.

Note: - you can unmount the remote folder using the regular umount command like:
umount ~/mnt
or using fuse:
fusermount -u /mnt

This article will show how you can rebuild any debian package. You might need to rebuild a package for various reasons: add/remove some compilation options, make some changes to the sources, or compile a newer version from testing/sid into stable, etc. Regardless of your reason, this can be done very easy using debian tools.

First you will need to have some basic debian building tools installed:
apt-get install devscripts build-essential

1. Get the source package

Debian repositories contain the sources for all existing debian packages. In order to get a source package you will need to have in your /etc/apt/sources.list a deb-src line (this is exactly as a regular deb repository line, but it is for sources). This will look like:
deb-src http://ftp.us.debian.org/debian/ etch main non-free contrib
change it accordingly to your needs (a close mirror, testing or sid instead of etch, and so on).

Once you have your sources file updated refresh your packages lists:
apt-get update

Now you can install the source package using:
apt-get source <package>
this will download the source package inside the local folder, so you might want to change to a proper location before doing this. Also as the final step it verifies and uncompresses the package and prepares it for compilation. You will just have to move in the newly created folder (name and version of the package).

2. Installing dependencies

The compilation of each package will have its own unique set of dependencies, based on the software itself. You will need to install them prior to the actual compilation, if not the process will most certainly fail. To do this we will again rely on the powerful apt:
apt-get build-dep <package>
this will pull from your current repository the needed dependencies, and install them.

3. Make your changes and rebuild the package

Now is the time to make your changes. This is outside the scope of this post, but normally you will either modify source files of the package or make changes inside the debian compilation scripts (or maybe no changes are needed and you are doing just a recompile on a different architecture). Inside the debian folder you have important files like rules (that contain the compilation options among others), changelog if you want to add your own version you will need to add it here, and so on. Check the debian maintainer’s guide for full details.

Once you’ve made your changes you can start the compilation using:
cd <package-ver>
debuild -us -uc
We used debuild -us -uc since we are not the maintainer of the package and we will not be able to sign the package.

You will find the debian packages that you have just compiled one folder above, among some other files (the initial sources, compilation logs, etc.). You can either put them in a local repository and install them using apt-get as usual, or you can just install them using dpkg:
cd ..
dpkg -i <package_file.deb>

Finally here is a real life example

Ok, let’s see how this works for a real package. Let’s say we want to recompile for some reason the mysql server package (mysql-server-5.0). Here is how this would work:
apt-get source mysql-server-5.0
apt-get build-dep mysql-server-5.0
cd mysql-dfsg-5.0-5.0.32
debuild -us -uc
cd ..
dpkg -i *.deb

Canonical will announce Netbook Remix, its version of Ubuntu Linux tailored for mobile devices, in two weeks, Chief Executive Mark Shuttleworth said.

“We’re announcing it in the first week of June. It’s called the Netbook Remix,” Shuttleworth said in an interview with the Guardian. “We’re working with Intel, which produces chips custom-made for this sector.”

Ubuntu has been working on a mobile version of its operating system for months. In an April interview about the release of the new Hardy Heron version of Ubuntu, Shuttleworth said the mobile version is sufficiently important that developing it is worth pushing back the company’s move to profitability. The company has engineers working on-site at Intel, he added.

Ubuntu still has plenty of buzz, a remarkable feat given how many new versions of Linux have fallen by the wayside over the years. However, it’s not all smooth sailing: the Ubuntu Live conference that had been scheduled for July has been canceled, though some content from the show is moving to the Open Source Convention.

Whether you’re looking to save on keystrokes, avoid errors or simply show off how terse and clever you can be, Unix systems offer a lot of options for smart use of the command line. In this week’s column, we’ll look at a few of my current favorite command line tricks.

Filename Completion

Ever since my early days with csh, I was hooked on filename completion. In csh, I would “set filec” and, afterwards, I could press the escape key to complete a filename up to the point of a conflict. For example, if I had two files named “this-is-a-long-filename” and “this-is-a-longer-filename” in my home directory, I could type “more this”, press Escape and “more this-is-a-long” would appear on my screen. At that point, I could type “-” or “e” and press Escape again for the remainder of my preferred filename to appear.

Filename completion works with pathnames too. So, I can type /u and press Escape to get /usr, type op and press Escape to turn that into /usr/openwin and so on. Over the years, I’ve saved myself a lot of annoyance by letting the system figure out a good portion of what I was after.

In bash, filename completion uses the Tab key instead of the Escape key.

Command Completion

Bash takes the concept of filename completion a step further to give us command completion. So, not only can I type “more this” and press Tab to complete filenames, I can type ifc, press Tab and have the system turn this into ifconfig. In other words, I can use this feature to complete command names.

Brace Expansion

Another useful trick of bash takes a brace-enclosed list of strings and expands them. For example, we could type:

$ echo {a,b,c}
a b c

While this simplest of examples doesn’t illustrate the utility of brace expansion, it shows you what the command does. Now let’s look at what happens when you string more than one brace-delimited list together:

$ echo {0,1}{0,1}
00 01 10 11

In this example, we’ve generated a list of all 2-digit binary values. This example better illustrates how the list items are expanded. Want to do the same for three-digit octal? No problem:

bash-2.05$ echo {0,1,2,3,4,5,6,7}{0,1,2,3,4,5,6,7}{0,1,2,3,4,5,6,7}
000 001 002 003 004 005 006 007 010 011 012 013 014 015 016 017 020 021 022 023
024 025 026 027 030 031 032 033 034 035 036 037 040 041 042 043 044 045 046 047
050 051 052 053 054 055 056 057 060 061 062 063 064 065 066 067 070 071 072 073
074 075 076 077 100 101 102 103 104 105 106 107 110 111 112 113 114 115 116 117
120 121 122 123 124 125 126 127 130 131 132 133 134 135 136 137 140 141 142 143
144 145 146 147 150 151 152 153 154 155 156 157 160 161 162 163 164 165 166 167
170 171 172 173 174 175 176 177 200 201 202 203 204 205 206 207 210 211 212 213
214 215 216 217 220 221 222 223 224 225 226 227 230 231 232 233 234 235 236 237
240 241 242 243 244 245 246 247 250 251 252 253 254 255 256 257 260 261 262 263
264 265 266 267 270 271 272 273 274 275 276 277 300 301 302 303 304 305 306 307
310 311 312 313 314 315 316 317 320 321 322 323 324 325 326 327 330 331 332 333
334 335 336 337 340 341 342 343 344 345 346 347 350 351 352 353 354 355 356 357
360 361 362 363 364 365 366 367 370 371 372 373 374 375 376 377 400 401 402 403
404 405 406 407 410 411 412 413 414 415 416 417 420 421 422 423 424 425 426 427
430 431 432 433 434 435 436 437 440 441 442 443 444 445 446 447 450 451 452 453
454 455 456 457 460 461 462 463 464 465 466 467 470 471 472 473 474 475 476 477
500 501 502 503 504 505 506 507 510 511 512 513 514 515 516 517 520 521 522 523
524 525 526 527 530 531 532 533 534 535 536 537 540 541 542 543 544 545 546 547
550 551 552 553 554 555 556 557 560 561 562 563 564 565 566 567 570 571 572 573
574 575 576 577 600 601 602 603 604 605 606 607 610 611 612 613 614 615 616 617
620 621 622 623 624 625 626 627 630 631 632 633 634 635 636 637 640 641 642 643
644 645 646 647 650 651 652 653 654 655 656 657 660 661 662 663 664 665 666 667
670 671 672 673 674 675 676 677 700 701 702 703 704 705 706 707 710 711 712 713
714 715 716 717 720 721 722 723 724 725 726 727 730 731 732 733 734 735 736 737
740 741 742 743 744 745 746 747 750 751 752 753 754 755 756 757 760 761 762 763
764 765 766 767 770 771 772 773 774 775 776 777

More practical examples of brace expansion include commands like these that create backup copies of /etc/passwd and /etc/shadow files:

cp /etc/passwd{,.bak}
cp /etc/shadow{,.bak}

These two commands expand to:
cp /etc/passwd /etc/passwd.bak
cp /etc/shadow /etc/shadow.bak

Notice that the two-element lists contain one empty string and the string “.bak”.

Turning this trick into an extremely simple script make backing up individual files amazingly simple. Let’s say that I call this script “bak” and put it in /usr/local/bin. Then, any time I want to edit a critical file, I can type “bak ” first and know I have a backup.

#!/bin/bash

cp $1{,.bak}

Of course, you might like this one even better. It can save any number of backups (but not more than one a day!):

#!/bin/bash

cp $1{,.`date +%m%d%y`}

Here’s an example of this script in action:
bash# bak /etc/passwd
bash# bak /etc/shadow
bash# ls -l /etc/passwd*
-r–r–r–   1 root     sys         2529 Apr 10 12:56 passwd
-r–r–r–   1 root     other       2529 Apr 10 15:29 passwd.041306
bash# ls -l shadow*
-r——–   1 root     sys         1510 Apr 10 12:56 shadow
-r——–   1 root     other       1510 Apr 10 15:30 shadow.041006

Return Codes

I’ve found myself making increasing use of return codes to determine how my scripts are running. This little loop for reading files from my tape drive extracts tar files until there are no more. As soon as we try to read past the last file, the return code is non-zero and the while loop stops.

echo “Reading files from tape …”

while [ $? == 0 ]; do
  tar xvf /dev/rmt/0hn 2> /dev/null
done

Return codes also simplify my scripting. Instead of using a test like this:

status=`ping myserver | awk ‘{print $3}’`
if [ "$status" != "alive" ]; then
   echo OOPS
fi

I can reduce the complexity to this:

ping myserver
if [ $? != 0 ]; then
   echo OOPS
fi

Not exactly a Unix trick, but another time-saver that I’ve come to appreciate is PuTTY’s cut and paste. Using PuTTY, I can grab text from my screen simply by highlighting it and paste it simply by pressing on my right mouse button. Not having to slide down a menu to select a “copy” and then a “paste” option took a little getting used to, but now I love how quickly I can move text among the windows on my screen.

5. X11 Forwarding:

Did you know that you can run graphical X11 programs remotely, without using a program like remote desktop? This is really useful if you are a university student, and you need to run MatLAB, or any other X11 program, but you don’t have time to run to the Uni.

Here’s the quick coles notes way to run graphical programs from other computers:

ssh into the remote computer with the -X option, then, simply run your graphical app from the command line, and it will popup, provided that the server has X11 fowarding enabled.

4. The power of the TAB button:

Did you know that while you are typing at the terminal you can press the tab button, and it will auto-complete what you are typing? It’s pretty fantastic. It’s not wonder why many Linux Gurus prefer to use the terminal over a graphical user interface. For example, if you want to copy the file, myFile from /users/dug/desktop/ to /usr/local/bin all you have to do is start typing:

cp /u now hit tab, and it should complete /users. Hit the d key next and then hit tab again, this will complete: /users/dug now hit the d key again, and then tab, this will complete /users/dug/desktop If there are more options that start with the letter you are currently typing, it will display them if you hit the tab button twice.

3. The Mystery of the Arrow Up button:

Did you know that at any time while you are in the terminal, you can hit the up button, and use a command that you have previously used? The shell keeps track of everything you type (so be careful). This can be extremely useful. Often times, we end up using the very same commands, on the very same files. Why type it out twice? Use this trick, and make your terminal life more effective.

2. Colour your text in the terminal:

Stop using just a black and white terminal! Use colours for your directories, and executable files. This will make it much easier to distinguish your files, without using a slow GUI file manager. Get creative, and style out your own colours for your file system.

1. wget:

This utility has saved me, perhaps a hundred times in my career with Linux. Often times, we get stuck in a terminal shell, without a terminal web browser like lynx. How can we download a specific file that will save or patch our system without a web browser?

Well wget lets you do just that. simply type wget into the terminal, and then the website address. This will retrieve any file on the world wide web, and place it on your system.

______________________________________________________________________

Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!