The Author – Bart Busschots
Creative Commons
Unless otherwise stated, the content on this site is licensed under Creative Commons Attribution, Noncommercial, No Derivative Works 3.0 License
Dec
17
Why closed standards are a bad idea – a personal experience
Filed Under Computers & Tech on December 17, 2005 | Leave a Comment
I’ve rather made a name for myself as and anti-closed standards person on some boards I’m on and have perhaps pissed a few people off by implementing policies on file uploads etc. However, I recently got stung because I had saved important information (both my undergraduate theses) in a closed format a few years back. When I went to get at that information again a few weeks ago I realised I was in for a battle because the format I had saved the data in was no longer supported and since it is a closed standard no one else could make a viewer or a converter for it.
No prizes for guessing which company swallowed both my theses, it was of course MicroSoft. When I was in 4th year I had discovered an obscure but really cool tool that came with MS Office 97 called "Binder". This allowed you to build up a document out of lots of sub-documents of any MS Office type. In other words you could have a separate Word Document for each chapter making it much easier to edit and also include Excel spreadsheets etc. All these sub-documents could then be printed as one document and Binder would make sure all the pages were numbered correctly for you. Binder saved all your sub-documents in one file in its own format (.obd file).
When I went to convert my thesses to PDF for publication on my website I was horrified to find that neither Office 2000 nor Office XP had a clue how to open an Office Binder file. Some googling on the matter revealed that MS had abandoned Binder from Office 2000 on and had not bothered to even bundel a converter/extractor or anything like that. If you had used Binder your documents were gone. MS obviously don’t give a damd about their customers if they dare use any of the more obscure tools they charge you an arm and a leg for. I was majorly not impressed.
In the end I had to find a machine that still had Office 97 and then install a PDF printer driver to get my theses back out. It took me weeks and a lot of hassle and even now my CS thesis is missing two appendices because I had done those in MS Project and that too disappeared into the ether and I haven’t been able to find a machine with that installed anywhere yet.
Bottom line, if you value your data save it in an open format so that people other than the company that wrote the software you use can write readers/converters so you can always get at your data. Proprietary data formats are dangerous so don’t trust your data to the whims of people like MicroSoft!
Dec
15
JellyfiSSH for OS X – SSH Heaven
Filed Under Computers & Tech on December 15, 2005 | Leave a Comment
OS X comes with SSH built in but it is command line only and gives you no easy way to store all your bookmarks or customise your SSH windows. For your average user this is probably not a problem but when you have to SSH to as many servers as I do it becomes a real shortcoming. However, after much googling I found the answer – JellyfiSSH for OS X.
First things first, you can get JellyfiSSH from here: www.arenasoftware.com/grepsoft
Needless to say it does the basics like allow you to save hostnames, usernames and tunnels but it also allows you to group your bookmarks and, best of all, to have different window settings for each bookmark. The OS X terminal is very powerful and very configurable so rather than re-inventing the wheel what JellyfiSSH does is to spawn a terminal windows with your settings for you and then send the SSH command for your bookmark to that terminal.
Because the OS X terminal lets you set a background image this means you can set your backgrounds to different things for each server. I did up a template with the GIMP so my SSH shells now all have the name of the server in huge writing on the background and in the case of the servers here at work I’ve colour-coded them to have a red background if they are production servers and a blue background if they are fail-over/test/development servers. Basically, if I see red I take extra care because one slip-up could bring the entire campus network crashing down around us all! The other nice thing about this is that our servers in work are not called after their function because stuff gets moved from server to server all the time but by their hostnames which are all trees/fruits. Since I only started work here a few weeks ago I still get very confused as to what is what so I’ve added the function to the background image too so at a glance I can see that Larch is the production mail server etc.
Once you get everything set up just the way you like it you’ll never understand how you lived without it! Anyhow, below are some screen-shots from my system to show JellyFiSSH in action.
The Basic JellyfiSSH GUI
The Extended JellyfiSSH GUI
JellyfiSSH in Action
Dec
8
Publishing your Calendar with iCal
Filed Under Computers & Tech on December 8, 2005 | Leave a Comment
If you use iCal on multiple machines you would of course like to see your calendars from them all, well, if your mac has a permanent Internet connection here’s the FREE and easy way to do it. BTW the non-free but also very easy way to do it is to publish your calendars to your .mac account.
All you need for this to work is Mac that is visible on the Internet with an out-of-the-box install of Apache (comes with OS X whether you like it or not!). Then just follow these simple instructions to configure the Mac with web access to use WebDAV and then you can publish straigh from iCal as shown by the screen shots below.
Step 1
OR
Step 2
Step 3
Dec
8
Breezy Badger release of KUbuntu continues to dissapoint
Filed Under System Administration, Computers & Tech on | Leave a Comment
Following on from my last article about Breezy I’m afraid things have not gotten any better. KUbuntu is just broke! At first I thought the mac style control panel was really cool until I discovered that I can’t get into administrator mode on any of the dialogs. I click the button, enter the password, the border goes red, the panel goes blank, stays blank for some timeout period and then brings me back to the non-admin display. I can click that button all I want but I can never edit any settings that you need to be root for. Yet again not acceptable from a Linux that is supposed to be for "human beings".
Dec
7
SSH via a Socks proxy on OS X with connect.c
Filed Under Computers & Tech, System Administration on December 7, 2005 | 15 Comments
NOTE: tested on OS X 10.7 Lion, works fine!
These instructions are for setting up a mac to use connect.c to get SSH through a SOCKS proxy. If you are not using OS X this may still be of some use to you because connect.c will compile on Windows and *nix as well. If you’re in the NUIM oncampus accommodation and are having problems SSHing this could be the answer to your problems!
The first step is to get a copy of connect.c and compile it. The website contains instructions for doing this on other platforms but for the mac use:
gcc connect.c -o connect -lresolv
This will spool out a ream of warnings but don’t worry about that.
Then you have to copy this to a folder in the path and set up the correct permissions:
sudo cp connect /usr/bin sudo chmod 555 /usr/bin/connect sudo chown root:wheel /usr/bin/connect
At this stage connect.c is installed, you now need to tell SSH to use this proxy for any servers you want to connect to that is outside the campus.
To do this you need to add lines of this form to ~/.ssh/config:
Host xxx.yyy.com ProxyCommand connect -a none -S socks.yyy.com %h %p
The example above is for connection to xxx.yyy.com, you’ll need pairs like this for each host you want to connect to. You should separate the pairs with a bank line.
That’s it, you can now ssh as normal and ssh will use the SOCKS proxy.
ssh [email protected]
Dec
7
IPFW Firewall Script (Suitable for OS X)
Filed Under Computers & Tech, Security, System Administration on | Leave a Comment
I posted an article the other day about how to configure OS X to use a custom firewall script but explicitly didn’t discuss the actual rules, in this article I’m going to focus only on the firewall rules and assume that you are using an IPFW configuration that is working correctly on some OS that uses IPFW. Please note that I have tested these rules on OS X only but I can’t see why they wouldn’t work on any other IPFW enabled system.
So, without further ado, here is my /etc/rc.firewall (with all specific IP addresses blanked out of course!):
#!/bin/sh
#
# Declare variables
#
IPFW='/sbin/ipfw'
LOOPBACK_INTERFACE=lo0
PRI_DNS=XXX.XXX.XXX.XXX
SEC_DNS=XXX.XXX.XXX.XXX
#
# Flush the rules so we start with an empty pallet
#
$IPFW -f -q flush
#
# Do some house keeping
#
# allow through all genuinely local packets
$IPFW add 00001 allow ip from any to any via $LOOPBACK_INTERFACE
# deny all spoofed local packets
$IPFW add 00010 deny ip from 127.0.0.0/8 to any in
$IPFW add 00011 deny ip from any to 127.0.0.0/8 in
$IPFW add 00012 deny ip from 224.0.0.0/3 to any in
$IPFW add 00013 deny tcp from any to 224.0.0.0/3 in
# allow through established connections
$IPFW add 00020 allow ip from any to any established
# filter ICMP packets to only allow through some types
$IPFW add 00030 allow icmp from any to any icmptypes 0,3,4,8,11,12
$IPFW add 00031 deny icmp from any to any
# allow through DNS
$IPFW add 00040 allow udp from me to $PRI_DNS 53 keep-state
$IPFW add 00041 allow udp from me to $SEC_DNS 53 keep-state
# allow myself to make outgoing connections
$IPFW add 00050 allow tcp from me to any keep-state
$IPFW add 00051 allow udp from me to any keep-state
# allow through all DHCP packets
$IPFW add 00060 allow udp from any to any 67
$IPFW add 00061 allow udp from any to any 68
# deny UDP
$IPFW add 00070 deny udp from any to any
#
# Allow services
#
# ssh just from within my departments range
$IPFW add 00100 allow tcp from XXX.XXX.XXX.0:255.255.255.0 to me 22
#
# Allow in exceptions for me
#
# allows the FTP server to connect back to me for active FTP
$IPFW add 00200 allow tcp from XXX.XXX.XXX.XXX 20 to me
#
# end with deny all
#
$IPFW add 65534 deny ip from any to any
OK, so now I’m going to go through this bit by bit to explain why I’m doing things the way I am. There is logic behind each line and I’ve spent a lot of time and effort this week getting this right. I’ll also mention some pitfalls to look out for along the way.
I should also point out what I was trying to achieve with these rules. The first thing is that these rules allow me to go out on any port to anywhere I want, they are not designed to stop me doing stuff. Secondly, these rules are designed to expose as few as possible services on this machine and any services that are exposed should be exposed to as few hosts as possible. Finally, these rules are also designed to filter out a lot of the UDP rubbish floating round on the network I work on because of all the Windows boxes on it.
So, into the rules, the way I have it set up is that the only parts that you should need to edit are the top bit that defines the variables and the bottom bit that defines the services you want to open up, the bits in between that should not need to be edited as there are no specific IP addresses anywhere in them.
The first line is obviously a shebang line, if you don’t know what that is please stop reading now because you are not ready to set up a custom firewall script! So, the next bit is the definition of some variables:
IPFW='/sbin/ipfw'
LOOPBACK_INTERFACE=lo0
PRI_DNS=XXX.XXX.XXX.XXX
SEC_DNS=XXX.XXX.XXX.XXX
The first one is obviously defining the location of the IPFW binary and the second line is the definition of the loop-back interface. Be careful here, some scripts you see use lo* here and that is very dangerous, using it made my machine un-usable till I changed it back to lo0. The next two lines define the IP addresses for the DNS servers that the firewall should allow the machine to use.
The next thing you have to do is to flush all the rules that may be in the firewall already out so you know exactly what will be in there when your script ends, to do this we use the flush command but we must also use the -f flag to force it to do the flush without asking us if we are sure.
$IPFW -f -q flush
The next stage is to ensure that all loopback traffic can flow but that no one can spoof the localhost address on another interface, anyone doing so is definitely up to no good!
# allow through all genuinely local packets
$IPFW add 00001 allow ip from any to any via $LOOPBACK_INTERFACE
# deny all spoofed local packets
$IPFW add 00010 deny ip from 127.0.0.0/8 to any in
$IPFW add 00011 deny ip from any to 127.0.0.0/8 in
The next two lines are standard in all firewalls OS X’s firewall interface generates so I have added them to my rules too. They block certain types of multi-cast traffic.
$IPFW add 00012 deny ip from 224.0.0.0/3 to any in
$IPFW add 00013 deny tcp from any to 224.0.0.0/3 in
The next thing to do is to allow packets belonging to contections that have already been established to pass through the firewall without needing to be checked off all the rules again. This a great optimisation but is only any good if you have it close to the start of your rules.
$IPFW add 00020 allow ip from any to any established
At this point the next thing we are going to deal with is ICMP packets. Many people block all of these packets but I am not a fan of that. ICMP is there for a good reason and blocking it will probably make your system administrator grumpy! The way I filter ICMP I can ping people, people can ping me, I can traceroute to people and people can traceroute to me. I am however still blocking loads of other potential ICMP traffic that is just not needed (note that to get traceroute working you also need UDP to be allowed out).
$IPFW add 00030 allow icmp from any to any icmptypes 0,3,4,8,11,12
$IPFW add 00031 deny icmp from any to any
Next I allow through DNS to my specific DNS servers. These rules are technically not needed if you decide to allow yourself to send out traffic on all UDP ports using a state-full rule (see rule 00051) but I like to put these in explicitly because I sometimes like to just kill all UDP connections later in the rules.
$IPFW add 00040 allow udp from me to $PRI_DNS 53 keep-state
$IPFW add 00041 allow udp from me to $SEC_DNS 53 keep-state
The next thing I do is allow myself to make outgoing connections to any host on any TCP port and to send UDP to any port on any host. If you want to be able to use traceroute you have to allow UDP traffic out. Again, if you allow all UDP out using a state-full rule like the one below you don’t need to explicitly allow DNS so you can leave out the two lines above if you wish.
$IPFW add 00050 allow tcp from me to any keep-state
$IPFW add 00051 allow udp from me to any keep-state
One more thing to bear in mind is that if you do not include rule 00051 above to allow out and back all UDP ports then you would need to explicitly allow NTP if you wanted to use it.
The next thing to do is to make sure that you let all DHCP packets through. If you don’t use DHCP you can leave these two lines out.
$IPFW add 00060 allow udp from any to any 67
$IPFW add 00061 allow udp from any to any 68
At this point I like to deny all UDP traffic because there is just so much of it on our network but you can leave this line out if you wish, the last line will catch these packets too. The reason I put this rule here is for efficiency.
$IPFW add 00070 deny udp from any to any
Then we get to the second last part of the script where we define the services on our machine that we will allow be visible (to part of) the outside world. I like to tie things down very tightly so that I expose as few services as possible to as as few people as possible, hence, I only have two entries in this part of the script (and one is not technically a service). The first thing I do is allow SSH access to my machine but ONLY from within the subnet used by people within my department, not to anyone else on campus or beyond.
$IPFW add 00100 allow tcp from 149.157.4.0:255.255.255.0 to me 22
The second entry I have in here is needed to allow me to use active FTP to communicate with a web server I have to publish stuff to.
$IPFW add 00200 allow tcp from ccintranet.nuim.ie 20 to me
Finally, AND MOST IMPORTANLY, you must end with a rule to deny all packets not yet accepted. If you don’t your rule set will be utterly pointless and your machine will be pretty much completely open.
$IPFW add 65534 deny ip from any to any
And there you have it, my full set of Firewall rules for OS X. Now, please note that although I’ve been working with IPFW rules for many years both on OS X and FreeBSD I would still not consider myself an expert, hence, these rules come with absolutely no guarantees. I’m confident they are an excellent set of rules that combine the best bits of the other scripts I found on the web for OS X but you will need to make your own judgement call before using them.
My final bit of advice is to NEVER put a line onto your rules that you do not understand 100%, if you’re not sure what a rule does it should not be in your script! When you are done with your rules you should then check them by getting someone to nmap your machine or by using a free online service like ShieldsUp! from Gibson Research Corporation. Happy firewalling!
Dec
5
The RIGHT way to set up a Custom Firewall on OS X
Filed Under Computers & Tech, Security, System Administration on December 5, 2005 | Leave a Comment
For the vast majority of home users the GUI in the OS X System Preferences application for managing your Firewall is all you’ll ever need, however, once you start wanting to have different rules for different hosts you have no choice but to either fork-out cash for something like Brickhouse or to get your hands dirty and write your own firewall rules with IPFW, the firewall that is part of OS X.
In this article I’m going to walk you through the right way to set up your mac to use custom IPFW rules, I am NOT going to give a tutorial on IPFW, I will be assuming that you are familiar with it and basic firewalling concepts. If you don’t know what you are doing with IPFW then DO NOT SET UP YOUR OWN CUSTOM RULES, you are playing with fire here people, if you mess them up you can actually stop your computer from working or leave it open to attack, neither are good!
The first step in setting up a custom firewall is to create a Startup item to manage it as a service. There are many different scripts out there to do this but most do this in a very poor way that does not use the standard files and is not controllable in the standard BSD way. The script I give here DOES do things the Right-Way(tm).
As root you will need to make a folder /Library/StartupItems/Firewall, in this folder you will have to create two files. The first is the script to control your firewall, the second is the list of parameters the OS needs about your firewall service.
Firstly, the script to control your firewall, this file MUST be named identically to the startup item so in this case Firewall. The script should contain the following:
#!/bin/sh
##
# Firewall
##
. /etc/rc.common
StartService ()
{
if [ "${FIREWALL:=-NO-}" = "-YES-" ]
then
ConsoleMessage "Starting Firewall"
sh /etc/rc.firewall > /dev/null
fi
}
StopService ()
{
ConsoleMessage "Stopping Firewall"
/sbin/ipfw -f -q flush
}
RestartService ()
{
StopService
StartService
}
RunService "$1"
This script has the advantage that it allows your firewall to be started, stopped and restarted like any OS service and it also allows the firewall to be enabled and disabled from /etc/hostconfig (without this you would have to delete the startup item to disable it). As you can see this file does not actually contain our firewall rules, those should be defined in /etc/rc.firewall.
The second file MUST be called StartupParameters.plist and should contain:
{
Description = "Firewall";
Provides = ("Firewall");
Requires = ("NetworkExtensions","Resolver");
OrderPreference = "Late";
Messages =
{
start = "Starting firewall";
stop = "Stopping firewall";
};
}
The next step is to create your custom firewall rules and store them in /etc/rc.firewall. As I said I am not going to go into a discussion on creating firewall rules in this article, I am assuming that you know what you are doing when it comes to creating firewalls with IPFW! Hence I am going to skip straight on to enabling the service in /etc/hostconfig. This is exceptionally simple, all you have to do is add the line:
FIREWALL=-YES-
to the end of the file.
That’s it, you now have a custom IPFW firewall running correctly on OS X. If at any stage you want to temporarily stop using your custom firewall all you have to do is stop the service with /Library/StartupItems/Firewall/Firewall stop and then set the entry for your firewall in /etc/hostconfig to FIREWALL=-NO- to disable it.
I may well do a follow-up article to this one discussing firewall rules for OS X and/or logging but I’ll make no promises!
Nov
30
Mighty Mouse – Mighty Disappointment
Filed Under Computers & Tech on November 30, 2005 | Leave a Comment
So, I got my very shinny new PowerMac (dual 2.0Ghz G5 with 2GB RAM) today and I’m just blown away by just about everything about it (it’s FAST, the Apple Cinema Display ROCKS) but one thing has proved a real disappointment, the Mighty Mouse that came free with it.
I have been playing with the settings for ages and all I can’t get the right "button" to do ctrl+click (right click to non-mac users) like any PC mouse will do when plugged into a mac. I can get it to do "Button 2" which is ctrl+click sometimes but only sometimes! The side buttons are useless and the only thing I can see them doing is giving people RSI! "Just squeeze" is what Apple say, gimme a bloody vice and I might have a chance! I don’t have particularly big hands and I can tell you now I’d do myself an injury if I had to use that "button" a lot.
Thank heavens there is a Logitech Comfort Cordless Desktop winging it’s way towards me as I type!
Nov
30
Breezy Badger release of KUbuntu very disappointing
Filed Under Computers & Tech on | Leave a Comment
I’d read some good things about the Breezy Badger release of Ubuntu on Planet MiNDS> so I figured I’d give it a go. Simply put, I’m not impressed. Things started off bad when the installer messed up because it made retarded assumptions and now that it’s up and running it is still causing me trouble.
Why the Breezy Badger Install sucks
Firstly, the installer made two assumptions that resulted in me having to intervene and switch to a terminal to sort it out. That’s all well and good for seasoned Linux Users but is totally un-acceptable for a distro that makes a big deal out of being "Linux for Human beings".
Firstly, I find it retarded that the installer even tries to go online, but it does. Fair enough. Where things get really retarded is when it tries to go online WITHOUT ASKING IF YOU NEED TO USE A PROXY! It just sat there. I figured it would time out ….. 5 minutes pass ….. another 5 minutes pass …. I give up and switch to a terminal and kill the process. The installer recovers but skips some setup steps. It was all recoverable later but only with some vi editing and farting round on the command line. Again, no problem at all for a seasoned Linux user but a really big deal for Human Being like my mother!
Secondly Breezy decided that after it had detected my graphics card it should set the resolution, not to a safe number like Windows or OS X would do nor did it ask me what I wanted like Fedora does, nope, it just decided to set the resolution as high as the graphics card can go. Thing is my monitor can’t go as high as my graphics card so as soon as my machine re-booted after the install I got a blank screen when X started and a message from my monitor telling me it couldn’t handle what it was being fed. I fixed it by firing up a terminal and editing /etc/X11/xorg.conf but again, no average user is going to be able, or willing, to do that!
In summation, the installer could have saved me a lot of bother and made the whole experience more pleasant by asking me two simple questions:
- Do you use a proxy and if so where is it?
- What resolution would you like from this list your graphics card can handle?
These are simple things that would have made a huge difference and that the Fedora installer lets you do in a nice GUI. When it comes to installers, KUbuntu is FAR behind Fedora as far as the average user is concerned.
After the Installation
There are also two things that are really annoying me now that the system is installed. Firstly, I installed both FireFox and Thunderbird with apt yet when I try to open a link from within Thunderbird NOTHING happens. It’s not that it uses the wrong browser, it just doesn’t use ANY browser! I’ve been copying and pasting links all day and quite frankly it’s a real PITA!
Secondly, I can’t get the MS fonts from apt like I could on the previous release of KUbuntu. I’ve enabled all the repositories and I’ve tried every apt-cache search permutation I can think of and still no joy. It says there is a package that other packages refer to that does what I need but it can’t find the blooming thing!
On a less important note, Niall gave me exceptionally high hopes on the shinneyness of the GUI describing it as "OSX shinny" in his recent post about Breezy, but I was disappointed. It’s nice, very nice even and certainly nicer than the previous KUbuntu or the latest Fedora but it’s still far from OS X shinny I’m afraid.
Conclusion
If you are a Human Being and you want to use Linux, use Fedora!
Links
- Ubuntu – www.ubuntulinux.org
- Fedora – www.fedora.redhat.com
Nov
19
Learn from my mistake – always backup your backup scripts
Filed Under Computers & Tech on November 19, 2005 | Leave a Comment
On the one hand I should be ecstatic, having just suffered a disk failure on a production server I have all services restored and no data has been lost. However, I’m quite grumpy because the one thing I didn’t backup were my custom backup scripts that did me such sterling service! I now have to start from scratch and all I remember about the old scripts was that they were a massive PITA to write. This is one mistake I won’t be making again in a hurry!