Martello

I’m still a few years off 40 but have just identified candidate number one on the list of things I’d like for my birthday on that date. Forget your Ford Mustang or your Harley Davidson – I want me a trip to space … and Sir Richard Branson is just the man to get me there.

Check out Virgin Galactic.

I installed Solaris 10 x86 in a VMware Virtual Machine on a laptop earlier this week. It was mostly a straightforward process as I’d used VMware before to install Ubuntu Linux on a number of desktop systems. However, I did run into some trouble on the networking front.

The Problem

Whenever I generated a large amount of network traffic (i.e. copy a 300MB file onto it), the network driver (pcn0) seemed to fall over and die, rendering the VM unreachable from the outside world. I was using the SSH copy tool (scp) tool to carry out the file copy and the problem manifested itself by causing scp to report that the copy was stalled – a state from which it never returned. When I investigated from the system console, the pcn0 interface no longer had an IP address (but was still up). I had to reboot the VM to recover from this.

The Solution

In the end, the solution was to install VMware Tools which actually installs a different network driver (vmxnet) in place of the pcn driver. After VMware Tools was installed I did have to manually rename some of the networking files in /etc (hostname.pcn0 to hostname.vmxnet0 and dhcp.pcn0 to dhcp.vmxnet0) to get the system back on the network. But once I did that (and rebooted), every worked fine and I haven’t had any problems since.
If you happen to have a DVD/CD mounted in the VM (either physically or via ISO image), you should unmount if before attempting the VMware Tools installation as this process tries to mount an ISO image as part of the installation. If you fail to do this, the VMware Tools installation process will pretty much just sit there and give you no feedback as to what’s happening. Despite this, I am still a big fan of VMware and of Solaris.

I used Solaris 10 U3 (10/06) and VMware Server for Windows 1.0.3 Build 44356.

Today marks the official launch of the new All About Me website.

“All About Me produces beautifully presented personal stories that uncover historical, musical and sporting details, along with some interesting facts, all from a special date (or year) in someone’s life.”

Christmas is coming so don’t be stuck – get your orders in now!

If you have any comments or feedback about the new site, please let me know.

http://www.allaboutme.ie | info@allaboutme.ie

Objective

The objective of this exercise is to enable remote systems (clients) to be able to write to the System Log on a central Log Server (server), without losing the ability to write to their own local system log. This is achieved by creating a reverse SSH tunnel from the server to each client (on a special port) such that if the client configures their system log to use that port, the log entry will be sent across the tunnel to the log server.

Configuring SSH Access between Client and Server

The server will need to create an SSH connection to each client. The SSH tunnel will be initiated by the root user at the server but SSH connections by root have been disabled on all of my clients (for obvious reasons) so we will need to use a non-root user to create the SSH tunnel (e.g. someuser). The steps below were used to set up SSH access between server and client:

1. Create a public key on the server as the user who will initiate the SSH tunnel to the clients (root)
   

   server# ssh-keygen –t rsa

2. Copy the resultant public key file to the SSH directory for the someuser at the client
   

   server# scp /.ssh/id_rsa.pub someuser@remotehost:

3. At the client, append the public key file just copied to the ~someuser/.ssh/uthorized_keys file

The server should now be able to crate an unchallenged SSH connection to the client (as user someuser)

Configuring SSH Tunnelling

Syslog normally uses port 514 and it follows that this is the port that would need to be tunnelled from the clients to the server in order to enable remote logging. However, the non-root user at the client (someuser) will not be allowed to open port 514 since it is below the range of ports it has access to (only root can access ports below 1024 on Unix). Therefore, what we require is a tunnelled connection from a port above 1024, say 1514. If you are using a firewall or IP Packet Filtering software, you will also need to configure this to allow TCP traffic on port 514 at the server.

Use the following command to test the reverse SSH tunnel between the server and client:

server# /usr/bin/ssh -nNTx -R 1514:127.0.0.1:514 someuser@remotehost.domain.com

If this works, then proceed to the next step. If it does not, try adding –vv to the ssh command to see additional information about why. I had a problem here and it turned out that port forwarding was disabled at my client. To enable port forwarding, I modified the SSH configuration after which I restarted SSH at the client:

client# vi /etc/ssh/sshd_config
Change the value of AllowTcpForwarding to yes
client# svcadm refresh ssh

Automating SSH Tunnelling

To enable the server to automatically create a reverse tunnel to a given client, the following entry should be added to the /etc/inittab file at the server:

log1:3:respawn:/usr/bin/ssh –nNTx
-R 1514:127.0.0.1:514
someuser@remotehost.domain.com > /dev/null 2>&1

This should occupy a single line only (but has been split over several lines here to increase readability). This someuser and remotehost.domain.com should be replaced with a valid user and client hostname for your system.

Configuring the Log Server

1. Download the syslog-ng package from campin.net and copy it to the system that will become the loghost (do not install it yet). You could obtain a copy of syslog-ng from sunfreeware.com but the one from campin.net installs as a proper SMF service on Solaris and is a cleaner package to work with.
2. Now remove the existing system-log service from the server. This is required so that syslog-ng can become the primary system logging service on this system.
   

   # svcadm disable system-log
# svccfg delete system-log

3. Install the syslog-ng package downloaded above:
   

   # pkgadd –d NCsysng-1.6.7-1.pkg

4. Ensure that it is listed as a valid service
   

   # svcs –a | grep system-log-ng

5. Edit the configuration file /usr/local/etc/syslog-ng/syslog-ng.conf (you might like to take a copy of the existing file first) and edit as appropriate:
   

   options {
check_hostname(yes);
keep_hostname(yes);
chain_hostnames(no);
};
source inputs {
internal();
sun-streams("/dev/log");
udp(ip("127.0.0.1"));
tcp(ip("127.0.0.1") max_connections(100) keep-alive(yes));
};
destination logfile {
file("/var/adm/syslog-ng/$HOST/$YEAR/$MONTH/$FACILITY.$YEAR$MONTH$DAY"
owner(root) group(root) perm(0600)
create_dirs(yes) dir_perm(0700));
};
log {
source(inputs);
destination(logfile);
};


6. Start the new syslog-ng service
   

   # svcadm restart system-log-ng

7. Verify that the service is operating correctly (should not be listed in output from command below)
   

   # svcs -xv system-log-ng

Configuring the Log Client

Repeat steps 1-7 above but in Step 5, add the following 2 additional settings to the configuration file:

destination remote {
tcp("127.0.0.1" port(1514));
};
log {
source(inputs);
destination(remote);
};


Note the inclusion of 127.0.0.1 and port(1514) here. This tells the syslog service to write to port 1514 on the local system. This port represents one end of the SSH tunnel and writing to it will result is the log entry being sent to port 514 on the log server, which will result in a new entry on that log server.

Notes

1. Some sites recommend using the keep-alive(yes) setting with the tcp() function above on the server and the client (to avoid SSH hang-ups). However, I found that this is not supported at the client and it caused my system-log-ng service to enter maintenance mode at the client. The reason given by svcs –xv was “restarting too quickly” which was very vague. I ended up searching through the manifest files for the system-log-ng service to see what command-line it was actually executing (/usr/local/sbin/syslog-ng) and then running that by hand. It was only then that I saw an error indicating an invalid parameter in my configuration file.
2. The use of ip("127.0.0.1") in tcp() and udp() in the server configuration ensures that the log server will only listen for local traffic on port 514 on that system. This is more secure.

Useful Links

• Syslog-NQ FAQ
• Remote Logging with SSH and Syslog-NG
• Replacing syslog on Solaris 10 with syslog-ng

Best of luck!

It beggars belief that in the current climate of international terrorism, someone could be so stupid that they would actually enter an International Airport wearing a circuit board with some wires and flashing lights on their T-Shirt.

We’ve all heard the not-so funny stories about the Irish guy who joked with the check-in attendant about the likely contents of his luggage and found himself in jail for several weeks as a result. But this one really does take the biscuit (or bread board to the techies out there).

I mean, what did she think they would say?

Source: SlashDot

Byte and Switch are compiling a list of the worlds biggest Storage Area Networks (SAN) and have release some of their initial findings. The purpose of the study to assess some of the lessons learned by corporations when scaling to such gargantuan levels of storage.

The results so far are utterly astonishing and the article is well worth reading. Impressive enough is the fact that the top five each have active storage capacities in the order of Petabytes (PB) but also that the San Diego Supercomputer Centre has over 18PB of tape storage (yes, that’s right, tape) and the Department of Defense has over 20,000 Fibre Channel switch ports.

Here is a summary of the top 5 (so far) showing the key suppliers in each case.

-

Particularly interesting (but not entirely surprising) is the high use of Sun and/or SGI equipment by four of the above.

Source: SlashDot

Your friend and mine, the inimitable Smiley Face turned 25 years old yesterday (Wednesday, 19 September 2007). The only shocking thing about this is that when I saw the phrase “25 years ago” in the article, my brain immediately thought “that’d be around 1975 wouldn’t it?“.

Imagine my surprise (and subsequent disappointment) when I realised that 25 years ago is in fact 1982. I must be getting older!

Source: SlashDot

Incredibly, another Chinese man has died from playing computer games. Apparently, he was attending some sort of online gaming marathon in an Internet cafe and fainted from exhaustion after 3 days playing non-stop. I knew there were some serious gamers out there but didn’t think they would actually risk their health and, more importantly, their life for the sake of it.

Source: TheStar.com

After you install Solaris on a system you must register it with Sun before you can do anything useful with it (in particular, apply patches). The most common way of doing this is via the Update Manager application (/usr/bin/updatemanager) which normally runs the registration wizard the first time it is used. However, this application requires a graphical terminal which you many not always have.

So, here is how to register your Solaris system from the command-line:

1. Create a Registration properties file (copy a sample one already on the system)

# cp /usr/lib/breg/data/RegistrationProfile.properties /tmp/myreg.properties

2. Add your Sun Developer Connection (SDC) username and password to the new file and save

# vi /tmp/myreg.properties

3. Register the system as follows:

# sconadm -a -r /tmp/myreg.properties

That should be all that you need to do. There is also no need to retain the properties file.