Me in IT UNIX/Linux consultancy

In May 2008, OpenBSD 4.3 will be released. Check the new features of OpenBSD 4.3 for a full list. These are the features that I like best:

• New tools: snmpd(8), implementing the Simple Network Management Protocol.
• New functionality: The periodic security(8) reports now include package changes.
• Assorted improvements and code cleanup: The disklabel(8) -E mode does not allow manual editing of the 'c' partition, which is always set to cover the entire disk.
• OpenSSH 4.8: Added chroot(2) support for sshd(8), controlled by a new option "ChrootDirectory".
• Some highlights: Gnome 2.20.3.

The OpenBSD team has been working hard for (at least) the last half year! Thanks!

The results are in at the Pwn2Own Contest held at the CanSecWest conference in Vancouver. The competition pitted a fully-patched version of Windows Vista with SP1 versus Mac's Leopard OS and Linux's Ubuntu. The idea of the contest is that if you can find an exploit in and take control of one of the three machines' OSes on the first day, then you win $20,000 USD plus the machine that you hacked. On the second day, they drop the bounty to $10,000 USD and open up some common third party software. Finally, the third day drops the prize to $5000 and opens up a large pool of commonly used software. As a testament to the robust security of all three OSes, none of the competitors attempted to crack them on the first day.

On day two, Independent Security Evaluators sniped Leopard via an unknown vulnerability in Apple's Safari browser. On day three, Shane Macaulay tagged Vista through Adobe's Flash software which is one of the most common pieces of software found on Windows machines of all varieties. Needless to say, that's a gigantic security hole that can potentially affect a multitude of Windows users, so if you're a Win-nut, you might want to stay away from any unknown flash applications until the security patch is released. For the Mac users--well, most of you never listen to common sense anyway, so hopefully your illustrious company will repair your damaged egos with the appropriate patch.

What about Ubuntu? Still untouched. Why? Because black-hats know that Windows machines and Macs are easier. Seriously, why bother with Linux when black-hats AND white-hats are locking the thing down for their own good? All the money is with the other two machines. Also, you can think of it this way: if you hacked the Ubuntu machine, you'd get a machine plus something you could download for free--with Windows and Leopard, you get the added monetary bonus of an overpriced OS.

Here is a very cool website to check how strong the password is that you are typing. Surprising how different passwords give different scores.

Would like to integrate a tool like this in applications like Drupal.

Bacause the article "Using Putty and an HTTP proxy to ssh anywhere through firewalls" was read well, here is the same trick, but then on Linux/UNIX/*BSD.

Imagine you are using a Linux/UNIX/*BSD system and you can't use ssh to go outside of your companies network. Here is a trick to ssh through the proxy.

Just to be sure, here is the list of requirements:

• A Linux/UNIX/*BSD workstation that has OpenSSH installed.
• A (company) proxy that enables you to surf the web.
• Not being able to use ssh to connect to machines on the internet. If you are able to ssh from your workstation directly to the destination, skip this article, you will not benefit from it.
• A program called corkscrew. You can download it and compile it. You do not need to install it in /usr/local/bin, but for this example we did. A location in your home directory will be sufficient.
• A Linux/UNIX machine to be used as an ssh server. I will use the host "machine-on-the-outside-network.example.com" in this example.

So, you got them all? Let's go then.

Finding out what proxy you are using

If you are lucky you can just open the preferences of your webbrowser and see what proxy (and ports, mostly 3128 or 8080. 80 could also be used.) you are using.
If you are using a PAC file and can't figure out what proxy you are using, follow these steps to check out what proxy you are using:

1. Open a website in your browser. Any website will do, but the best website will work better. ;-)
2. Open a terminal.
3. Run netstat -an You will see many entries, try looking (grep) for port 3128, 8080 or 80. Most proxies use one of these ports.
4. Take a not of the host that is the proxy. You will need this when configuring ssh. In my example, the proxy name will be: "proxy.on-the-inside-network.example.com, listening to port 3128.

Configuring OpenSSH to use that proxy

OpenSSH opens an optional configuration file when starting the client. You can set options for all sessions or specific hosts in ~/.ssh/config .
My configuration looks like this:

Now start the connection to see if it works:

Hopefully this will work for you, you might get more information if you add the -v switch to the ssh command.

When you are writing a shell script, you can set the shell script to debug, like this:

But; when you are using functions, the debugging is disabled for the functions. When you set -x the function will also debug, like this:

For people unknown to shell scripting, here is a little help on the "channels" stdout, (standard out, 1) stderr, (standard error, 2) and stdin (standard in, 0).

When you launch a command like ls, it will output the list of files to /dev/stdout . (a.k.a. channel 1 or standard out)

When a command has an error to report, it reports it to /dev/stderr . (a.k.a. channel 2 or standard error)

Normally both stdout and stderr are displayed at your screen, so you do not know about these channels. Lets do an experiment to demonstrate the different channels.

So what just happened?

1. ls This just list the files, no arguments are given, just the command ls
2. ls myfile nofile This command has two arguments, myfile exists, nofile does not exist. ls reports one file and one error.
3. ls myfile nofile > /dev/null Here the standard out is redirected to /dev/null, the bit bucket/trash-bin. This would mean only errors are reported, because that is not being sent over standard out.
4. ls myfile nofile 2> /dev/null In this example, the standard output is displayed, but the standard error (2) is thrown away by sending it to /dev/null.
5. ls myfile nofile > /dev/null 2>&1 You will see this syntax appended to commands when you want to disregard everything that commands produces, both standard out and standard error. What it literally means: "Send standard out to /dev/null. Send standard error to where standard out is going.

Here's a topic that's near and dear to me as a writer: books. Another thing I consider wonderful as a technophiliac is open source stuff. Now, combine those two and you get Open Source Books! It's a wonderful concept that combines the free mentality of source code with literary and informational texts. It allows the average person with internet access to have a library of extremely useful information at their fingertips, and it's a whole lot cheaper than taking classes!

One of the first places I ran across when Googling up open source books was the O'Reilly website. For O'reilly's open source books, they use the Creative Commons License which is somewhere between, as they put it, all rights reserved and no rights reserved. My general understanding of Creative Commons is that the license a little different with each book, and you generally can't edit and redistribute the book with your name added to it like you can with source code in the GPL. However, you can find quite a few titles on here from books that are out of print or otherwise (for one reason or another) released for free as either PDF or HTML texts. These are useful for finding that tidbit of information you read somewhere but can't find anymore.

Another great resource is Archive.org's Open Source Books where you will find, to date, nearly 14,000 books in various languages. They also have a section for the old Project Gutenburg that contains many older books that have gone out of print and are now in electronic format. PG has been on the net for a long time, and they've been providing free books to the world before it became hip.

Take advantage of these resources to educate yourself about a variety of topics.

Here is a simple telnet trick, so check if a port is open and responding as expected. Be aware that the check described here is a bit simplistic, but it does demonstrate the capabilities of telnet on the shell.

This will print "0" when everything is correct, and 1 when the grep did not work.

Imagine the rules of a social network would apply to corporate enterprises, these strange situations would arise:

• The boss and your manager would be chosen by you and your colleagues.
• Your manager or boss would be extremely popular today, but would be so yesterday tomorrow.
• Just like StumbleUpon traffic, it would be extremely busy with visitors this week, while next week could be so quiet.
• Your boss would be well connected on Linked In, have loads of friends on FaceBook and would own a huge area in My Space.
• You would spends hours trying to gain friends and fans in order to become boss tomorrow.
• Bosses over 40 would be thrown out tomorrow, colleagues of 19 or younger would determine the long term strategy.
• Being in the coffee corner for more than an hour would actually help your career.

Wow, that would actually be a very positive thing!

When administering an Apache web server, you will encounter moment when some of your clients, but hopefully you, published something that causes a rush of visitors to your web server. How do you manage that peak? Here are some tricks that you could use:

1. Limit the available slots

Apache has many performance related configuration options. When you run a small server, the default configuration of Apache might cause requests to be answered very slowly.
Apache runs on a desktop-comparable machine for my website, so I have altered these settings. The impact of this change was huge! Where the default settings would cause extreme high (100+) loads and extremely slow request, the web server runs healthy now.

At first this might scare you off; allowing less connections, but you will have to realize that a small server can't cope with 100+ simultaneous connections. Limiting the amount of connections will speed up the connected clients. Clients that visit your web server during busy times will have to wait a few seconds before being served.

2. Check the /server-status page

Configure Apache to allow you to see the status pages. This will help you identify what is using all the resources.

And run apachectl status and lynx http://localhost/server-status for extended information. Onlamps website explains what these values mean.

3. Move services to different machines

When you are in deep shit, move services like the database, email, domain name resolution, etc to a different machine. This will help you spread the load and will also help you identify where the problem exactly is.

4. Optimize code

After figuring out what virtual host eats all CPU cycles or available memory, check to see the (php) code. If you are not comfortable with it, let the user (and owner) do this. He/she is responsible for hir/her code.
This is the most difficult step to take and is in a gray area; it's not system administration, but sure comes close.