Use GMail’s SMTP gateway using the command line from !Ubuntu without lots of config #tips

I’m writing a few little scripts at the moment, and one of them needed to be able to send an e-mail. I’d not got around to sorting out what my SMTP gateway was from my ISP – but I do tend to use GMail’s SMTP gateway for non-essential stuff.

I thought I could easily setup sendmail, but no, that’s SCARY stuff, and then I thought of Postfix, but that needs an awful lot of configuration for an TLS based SMTP connection, so I did a bit of digging.

Thanks to this post over at the Ubuntu Forums, I worked out how to get a local port 10025 to run, but PHP kept complaining, so I next looked for a “sendmail replacement”, in comes nullmailer.

So, thankfully this is all rather easy.

  • sudo apt-get install openssl xinetd nullmailer
  • sudo tee /usr/bin/gmail-smtp <<EOF >/dev/null#!/bin/sh# Thanks to for this install guide/usr/bin/openssl s_client -connect -quiet 2>/dev/nullEOFsudo chmod +x /usr/bin/gmail-smtp
  • sudo tee /etc/xinetd.d/gmail-smtp <<EOF >/dev/null# default: on# description: Gmail SMTP wrapper for clients without SSL support# Thanks to for this install guideservice gmail-smtp{    disable         = no    bind            = localhost    port            = 10025    socket_type     = stream    protocol        = tcp    wait            = no    user            = root    server          = /usr/bin/gmail-smtp    type            = unlisted}EOFsudo /etc/init.d/xinetd reload
  • sudo tee /etc/nullmailer/remotes <<EOF >/dev/null127.0.0.1 smtp --port=10025 --user=your@user.tld --pass=Y0urC0mp3xGM@ilP@ssw0rdEOFsudo /etc/init.d/nullmailer reload

Setting all this lot up was pretty easy with these guides. There’s no reason why it wouldn’t work on any other version of Linux (provided you can install all these packages).

Good luck with your project!

Locally Monitoring Interfaces on Nokia Firewalls (and – by a link – McAfee Sidewinders) for Failover

I recently wrote a document on explaining how to monitor the interface of a McAfee sidewinder to see when it failed over. I don’t know why I didn’t write it on Posterous, but if you’re following me on Posterous, and you think that you might want to know how to use Perl to repeatedly loop over the same command, and show the results with a date stamp underneath it (a bit like the watch command) then you’ll find this page really useful. In the mean time, I’ve also written the same script for the CSH shell, which is used, amongst other places, on Nokia Firewalls.


One of our requirements with one of our customers is to perform regular and routine failover tests. As the interface is not responsive to providing information about when service has failed from Primary to Secondary and back again, I re-wrote the script I adjusted for McAfee Sidewinders to run on the SECONDARY NODE to show the interface address of one NIC every 5 seconds. I’ll also show how to slightly modify the script with different time delays and interface names. Please note, there may be much better ways of doing this. I needed something in a hurry, and this gave me what I needed. If you’ve got any better ideas, please drop me a note at or note below how to do it :)

Steps to perform

  1. SSH to the Secondary node.
  2. Check you’re not already primary with the command ifconfig eth-s1p1c0 | grep inet this should return one line showing something like inet mtu 1500 broadcast
  3. Type this
    while (-e /bin/csh)
    ifconfig eth-s1p1c0 | grep inet
    sleep 5
  4. Perform your action to provoke fail-over, which may be to unplug an interface attached to the primary firewall, reboot the firewall or unplug a switch directly attached to the firewall. In response (and after approx 1 minute, based on your HA configuration) you should now see in the script’s output, it now shows two lines (or maybe three) – as follows:

    inet mtu 1500
    inet broadcast
    inet broadcast
    vrrpmac 0:0:aa:bb:cc:dd
  5. Perform your failback and after 1 minute or so, it should revert to just the single line – or equivelent for your network.

In the bold section above, replace the interface name identified (here it’s eth-s1p1c0) with an interface you know will fail over, you can also make bigger or smaller the sleep command – here it’s 5 seconds, but there’s probably no reason why it couldn’t be 1 or 10.

Supporting multiple machines in GNOME using VNC

I was recently asked how to configure VNC for user support across a series of machines running GNOME. I’m in the process of trying out a few different platforms at the moment, and didn’t have my GNOME machine to hand and working right, so I decided to work it out from what I’ve done in the past. Here’s the bulk of the e-mail I sent him to try and help him out. Maybe this will help you at some point.

If you find any errors (especially around the option names in the actual dialogue boxes) please post a note so I can correct this!


On most GNOME based systems (which includes Fedora), you can active “Remote Desktop Sharing” for users.

Go to System -> Preferences -> Remote Desktop Sharing (or something similar). I’m afraid I’ve just recently moved my systems to KDE, so I don’t know the exact options, but I believe it’ll say something like “Enable remote connections” (tick that), and “User is prompted to permit connection” (this will be down to policy) and “Remote user needs to enter a password” (this will need some text to be entered).

Once you have these for one system, you can automatically set this for all the other computers.

From the command line, type
  gconftool-2 -R /desktop/gnome/remote_access

This will return all the settings you have made. Here’s mine:

 view_only = false                                         
 alternative_port = 5900                                   
 prompt_enabled = false                                    
 icon_visibility = client                                  
 lock_screen_on_disconnect = false                         
 disable_xdamage = false                                   
 mailto =                                                  
 use_alternative_port = false                              
 enabled = true                                            
 disable_background = false                                
 network_interface =                                       
 require_encryption = false                                
 authentication_methods = [vnc]                            
 vnc_password = &&&&&&&&&&&&                               
 use_upnp = false

(I’ve removed the password for my box)

You can use this gconftool to set the same variables on your computers you’ve already deployed, either per-user, as a default policy for each machine, or as a mandatory policy for each machine.

This article from Sun’s GNOME configuration guide explains how to set variables: while this is an overview of all of the GNOME configuration tool (including that article): and lastly, this is how “Vino” the VNC client for GNOME works:

I hope this helps you!

Taking the config from a McAfee Sidewinder for use in *something else*

I’m really learning to love the Sidewinder product line. Don’t get me wrong, it’s still got it’s foibles that make you go “Erm… OK”, but it is quite a clear step up from the Cyberguard Classic and the Secure Computing TSP device. The one area that had people stumped (that I’ve spoken to) though was how to get the config out in a way that could be re-used. The Classics used pretty standard text files everywhere, and you could just pull those out… tada, instant config. TSP had a single XML file which made extensive use of GUIDs to link hosts to groups, services to groups, host groups and service groups to rules, and so on. When we got to the Sidewinder, I made the mistake of thinking you could just do the same thing here…

Nope, Sidewinder would only export it’s policies in a securely encrypted format, that would only de-encrypt on another Sidewinder.

But hang on, what if someone wants to do a rule-base review on that box, and you don’t want to give them access to *everything*… how do you get around that then?

The simplest way seems to be to use a couple of commands, wrapped up in the TCSH foreach command, but to figure out what to select, you need to know how I got here.

There’s a command called cf which you run with administrator rights, by running srole – once you’re an admin, run the command

cf help

and this returns a list of configuration details you can do stuff with. Let’s pick one of these at random:

cf help ipaddr

This tells you that you can do cf ipaddr [add|delete|query] or at least something like that. The bit we’re most interested in right now though is query because that’ll give you some details. When I run cf ipaddr query or cf ipaddr q for short, it gives me back a bundle of lines like this:

ipaddr add name=I_Am_A_Name ipaddr= description=”
last_changed_by=’admin on Tue Jan 01 01:01:01 2001′

For those of you who know some unix syntax, you’ll realise that the indicates “ignore (or do something special with) the next character” – in this case, ignore it, because it’s the “New Line” character. You’ll recognise here that it’s saying you should add a new ipaddr object with a fixed name, fixed IP address and sets some other interesting data.

Not all of the list of things you can do stuff with is actually queryable though, so it might be worth picking and choosing what you do and don’t query. For brevity sake, here’s a list (space delimited) of the ones you can query:

accelerator acl adminuser agent antivirus appfilter audit auth burb burbgroup catgroups cert cluster cmd commandcenter config crontab daemond dhcrelay dns domain export failover fips fwregisterd gated geolocation host hostname ids ikmpd interface ipaddr iprange ips ipsec ipsresponse ipssig knownhosts lca license mvm netgroup netmap nss ntp package policy pool proxy qos reports routed server service servicegroup snmp ssl static subnet sysctl timeperiod timezone trustedsource udb ups urltranslation usergroup utt whitelist

Now, I don’t know what *all* of those do, but if you’ve spent any time wandering around the Sidewinder GUI, then you’ll recognise some of these terms – and that they participate in how the policy fits together. For a simple no-VPN policy, here’s the list (again space delimted) of things that I was most interested in:

burb burbgroup interface ipaddr iprange netgroup netmap policy proxy service servicegroup subnet

So, let’s do something useful here. We already know that we can run cf <object> query and it’ll return some data, but how would we do that for a whole bundle of these things? Re-enter stage left the foreach command. Anyone who’s done any programming knows about the for-next-loop style of loops, and some also know about the foreach loops. That’s all we’ll use here, and get something akin to a single config file (or multiple – you’ll see why in a second).

foreach fe ( burb burbgroup interface ipaddr iprange netgroup netmap policy proxy service servicegroup subnet )
cf $fe q >> config_file

You’ll notice that we’re putting that previous list of config options into a foreach loop, and using the variable fe when we’re using it against the cf command. You could replace config_file with config_file.$fe to ensure that you had a separate config file per object.

Run this little lot through a simple text processor (looking for the backslash character and then a new line, replace it with nothing) should give you an easy-to-parse list of objects and their variables. Of course, if you notice, those lines are also saying “add” – there’s no reason why you shouldn’t be able to prefix each of those <object> add lines with cf and paste that into your terminal to rebuild a firewall with a complete policy, but I’ll leave that as an exercise for the reader :)