I'll be back

My blog has been awfully neglected lately.

The company's merger meant a new look at the portfolio, to integrate and merge the offerings. Quite exciting, as several new sites mean access to loads more kit, including some top spec Sparc machines, which will be employed very quickly for the new generation of administration courses. The breadth of the combined customer base is demanding several new courses, at either end of the spectrum. Linux for desktop at one end, and top level enterprise server stuff at the other.

Teaching trips to all corners of the world add variety and excitement, but do nothing to relief time squeeze ;-)

All in all rather busy times for us! But I have so much to document, that hopefully this blog might start flowing again soon...

Choice is wonderful

There has been so much arguing about pros and cons of open source, I'm not going to start now. Developers and system architects having choice in selecting programs and having the Linus-given right to modify them and adjust them to their need is all truly great.

It may, however, give the rest of us headaches when trying to adjust our understanding of a command or program behaviour.

Take the login program. Originated quite early in the UNIX evolution. Linux implementation (look at the bottom of man login) refers to:
'BSD login 5.40 (5/9/89) by Michael Glad (glad@daimi.dk) for HP-UX.
Ported to Linux 0.12: Peter Orbaek (poe@daimi.aau.dk)'.

Both SuSE and Red Hat derivatives use this version of the program. However, if you are SuSE user, there is one more credit line you can see there:
'Added new features: ThorstenKukuk (kukuk@suse.de)'.

I have only realised that, when hours of trying and trying to make the /etc/securetty file work consistently failed, and I was reaching that well know to me desparation state.

In manual pages, under SPECIAL ACCESS RESTRICTIONS, where the behaviour of the two standard access files (securetty and usertty) are described, the behaviour of the securetty file is described, but on closer inspection, in the DESCRIPTION section it's stated:
'This login implementation does ignore /etc/nologin and /etc/securetty. You need to configure this in the PAM configuration file for login...' .

Why? Obviously the assumption is made that PAM ought to run at all times - a very sensible advice. But why force people? The worse implication to me is that if administrator decides to leave the PAM configuration out of the equation, the simple system access configuration is then missing altogether...

Apart of anything, it means that I cannot have an exercise in the 'generic' Linux course that can be done on both distributions. How annoying!

I'm not going to throw it out, though. It will act as a reminder for all of us, not to become complacent.

This is the beauty of UNIX and Linux - always keep you on your toes, make you test all solutions on every new platform, force you to test-run every script or program you want to port...

Which shell?

Finding which shell you are currently using is not difficult, the ps command can tell you this easily. However, if you are using several shells, identifying the current one can be rather involving, may require ps -f, to make sure that you are looking at the last one executed. his method has one inherent problem - relies on human ability to deduce the desired result. Approach very much prone to mistakes!

Whenever possible make the system do the hard work for you. We know that the current process ID is stored in the environmental variable $. You can therefore always check what the PID of the current shell is with:

$ echo $$

PID itself does not tell you which shell this is (if you have a mix of ksh, bash or any other you are still nonthewiser which one of them corresponds to the PID). Yyou can find the name of the process name ellegantly by interrogating the /proc filesystem, which stores all process information (in both UNIX and Linux, but on Linux has also all sorts of other hardware information).

Still using a reference to the $ variable, look in the /proc for the name of the corresponding program:

$ ls -l /proc/$$/exe

lrwxrwxrwx . . . /proc/25541/exe -> /bin/bash

If this is something you need to execute regularly, you can always create a little function and place it in one of the environmental files...

Back in action

I've spent last few months between holidays, teaching, flying and a combination of all three above. Rather busy and exciting times, and the QA-IQ merger put another layer of travel, presentations and meetings to this all.


Well, it looks like it's back to 'normal', whatever this may mean ;-)) - so back to Linux'ing, etc.


I've now moved to Linux almost entirely. The HP/XP laptop is now sitting on my desk at home most of the time, and is acting as a backup machine mostly. My old faithful VAIO V550 is back in action, with SuSE10 final beta.


I'm so impressed with it, that (backed up by the expressed needs of the public sector customers that IQ brought into the equation) I decided that for the first time Linux *IS* ready for the desktop, and consequently we need a Linux Desktop end user training. In the good QA tradition, will try to make it vendor (distributor in this case) independent, but will probably base it round Fedora 5 and Suse 10 installations.

Partition or not

This entry is in fact a reply I posted earlier today on our local LUG.

One of our guys lost a lot of data, because he accidentally done the rm at a wrong level of the /var branch. Any recovery work was made very difficult through the fact that his entire system was on a single partition.

So, the discussion about best partitioning practice emerged. Here are my comments:

My rule of thumb has always been to separate 'dynamic' from 'static' directories.

Every branch which I regard as 'dynamic' (ie written frequently by users or applications)
would go onto its own partition.

Typically these would be:
/var - log and spool files; these days also web pages - adjust the size for that
/home
/tmp
/usr - (mostly because of /usr/local, but also because historically it used to be
separate partition)
/boot - this is to keep the kernel's disk small, away from other stuff, and as contiguous
as possible
/any-other-application

Anything that you don't place on a separate partition will end up being part of the 'root disk'.
Don't forget a swap partition, and consider any particular needs of applications you are installing.

There seems to be a new school of thought, which suggests doing swap and root only (perhaps /boot as well).
I have heard arguments supporting that approach, but they obviously didn't convince me, as I can't remember what they were ;-)

Command line and GUI operations don't mix

When unzipping files (zipped originally under DOS) all permissions are messed up; notably the 'x' bit for shell scripts. That's nothing new really – always something to be aware of.

We have a set of Oracle installation (Linux) scripts that are stored on a Windows server. When needed, Dave "the NumbThumb" zips them up and sends them to us to play with. We are well used to adjusting access permissions, in fact we have a little script that looks after attributes of files that arrive from the dark side.

Today I've realised that mixing command line and GUI file manager is no good. Martin opened a GUI file manager and tried to run one of the scripts by double-clicking on the icon. Instead of running, an editor was opened. We quickly realised that the 'x' permission was missing. So I dropped into the command line, and did a quick:

# chmod +x *.sh

Run ls –l to confirm the change – OK. Martin tries to run the script again, but no difference: script didn't execute, but the editor opened again. Conclusion: if you have a GUI screen showing file icons, and change file attributes from the command line, don't expect GUI to take any notice.

The whole experience proves the very old recommendation of working with UNIX : when working on any particular task it’s best to stick to either the command line or GUI, don't mix them!

Playing cat and mouse with the cat builtin

Teaching Fundies. Using cat. Straightforward, hey?

One example in the book says, that you cannot redirect file onto itself using cat.
What should happen is:

$ cat file5 > file5
cat: file5: input file is output file

Delegates try this - "Alina, it doesn't work!". What does happen is:

$ cat file5 > file5
$

Several minutes of experimenting, and one of the delegates shouted with satisfaction: "Got it - cat is a built in".

What? As surprised as I was, in the ksh-20050202-1 cat is a builtin, in addition to the standard /bin/cat.

$ type cat
cat is a shell builtin version of /bin/cat

It may be a builtin implementation of /bin/cat, but there is behavioural difference. Perhaps not because of changes to what or how the two cat versions work, but due to the fact that one (the builtin) is operating in the same process as the calling shell, the other (/bin/cat) gets its own process space.

This could have VERY serious implications for shell scripts!

Consider the following:

$ cat x > x
$ echo $?
0

Then try the same, this time using external version:

$ /bin/cat x > x
/bin/cat: x: input file is output file
$ echo $?
1

How many programmers use full pathnames in their scripts? If you are one of them – well done, and you will have no problems with this particular cat!

If not, however (admit it!), any script written in the past, that uses cat's exit status will fail when ported to this version of ksh.

OK, so why would you like to use cat for testing? I don't know – but that's not the point!

Amazing resource page

When looking for an on-line IP subnet calculator during a class, we came across the site that managed to pull together a fantastic number of network and computer relating tools and resources.

The site itself is an American ISP. If they were in the UK, I would probably be talking to them about their services. Anybody who put so much effort and intelligence into creating this site would be worth considering...

A lesson to learn ;-)

Input redirection into a while loop

I'm teaching shell scripting in Stamford this week. Earlier today we had a discussion about data redirection to/from various programming statements like if, while, etc.

The offered approach was:

while read -r
do
command(s)
done 0< file

One of the students asked if you could have the redirection specified before the while, i.e:

0< file while read -r
do
command(s)
done

My immediate thought was - yes, it should work. I didn't offer my opinion at that point, though. Instead I answered the question with another one. I asked them if the following would work (my favourite example illustrating shell scan):

$ 1> file < /etc/passwd cat 2> /dev/null

I was truly convinced that the original question is another exhibition of the same behaviour, which allows to specify the I/O redirection at any (sensible) point of the command line.

Well, whereas the cat command line above will work OK, the original construct does not work! I have tried various combinations, and deduced that any alias, function or external command can have redirection specified before the command itself. However, when you are dealing with reserved words (programming keywords) or built-ins, the mechanism is not recognised, with a "command not found" error message.

Curious... Need to investigate it further, unless Clive comes back with an answer before then ;-)

URL code/decode tool

NLUG discussion on debugging htmp/php code lead to one of the participants quoting what I thought was an excellent tool for url decoding.

There are also very useful conversion tables.

Mac addresses in VMWare

I have recently noticed that when booting RHEL 4 in VMWare 5 (on my HPnc6120 laptop) the eth0 card would not initialise, with an error "MAC address is different than expected - failed".

After some googling, one theme appeared to recur: hardware modules in the kernel problem. However, I was convinced this was not the issue in my case, since I also have FC 5 and SuSE, to compare the kernel config files against. To complicate the matter further, I went down the totally wrong way to start with, assuming that the correct value was one reported by ip neigh show from another machine on the same home network. How silly of me - that other host was looking at the 'front end' configuration, whereas my problem was sitting behind the VM...

Eventually I managed to fix the problem, but without really understanding the reasons. What was the fix?

Well, I noticed that the HWADDR parameter in the /etc/sysconfig/network-scripts/ifcfg-eth0 had a different value than the one reported by the ip address show command.

I changed the HWADDR value to the one reported by the ip command, restarted the network with service network restart, and all was well. But I couldn't understand why (and how) the configuration file got changed - I could swear that I hadn't touched the parameter - ever! So I continued googling - and eventually went directly to the vmware site (another lesson learnt - should have gone there much sooner!) . The answer is well documented amongst their support pages, under "Maintaining and Changing the MAC Address of a Virtual Machine".

In a nutshell: virtual machine also means virtual MAC. The value assigned is unique, but is liable to be changed if you move the location of your VM.

This is exactly what happened to me. Since creating the RHEL4 VM, I have moved the "My Virtual Machines" folder (yes, XP) to a different drive - to fix XP synchronisation issues... But in turn , that messed up my RHEL installation.

Since my fix did the trick, I haven't studied the solutions they quote on their site - apparently you can tweak configuration files of VMWare itself to fix this.

I'm just happy that there was a 'good' reason for my problems. I hate fixing the unknown... It's just like replacing a blown fuse without knowing why it blew in the first place ;-)

Just a link... to a Microsoft blogger!

I've come across a very interesting discussion, started by a blog entry. It comes from an MS enclosure, and is a rather adventureous and brave expression of individual's views.

In the world where corporates often attempt to control the expression of views of their employees - usually through the fear of the unknown - this blog entry is proving that given a chance, most employees are prepared to stand by their bread provider, for better and for worse, in sickness and in health.

So, whether you agree with the preaching, analisys and recommendations or not - it does make interesting reading.

Linux in the air

Embedded Linux from LynuxWorks has been cleared for use in display, flight management and flight control systems in American commercial fleets.

"LynuxWorks becomes the first and only embedded operating system vendor to receive an Advisory Circular AC 20-148 acceptance letter from the FAA. "

See more at http://www.lynuxworks.com/corporate/press/2006/rsc-acceptance.php.

F-Spot - open source answer to Picassa

There is only a handful of applications which ensured that I continue using Windows. Picassa from Google (picture and video editing and management program) has definitely been one of them. Personally, I could never understand why they resist releasing a version of Picassa for Linux, but resist they do.

However, Linux community responded, as usual, and equivalent tool emerged. It's name is F-Spot, and comes from: http://f-spot.org/ F-Spot can be used on a non-Linux platform as well - if you download a Mono-Live CD , which comes with all sorts of goodies, F-Spot included.

The current version, 0.1.10, is actually quite good and stable. I haven't tested it fully yet, but it certainlyy is usable. The only feature I'm missing is video clips management, but this is very early days for the project, and developer team is keen to hear of any "shopping lists". Versioning is good, editing less comprehensive than that of Picassa's, but on the whole the time of good by to Windows is nearer and nearer.

Any QA person reading this - relax, I will maintain a system for course design applications, at least until we get to use some portable standard ;-)

New phase in X server evolution

For a while Novell seemed to head for the open source community doghouse, for working on the new X standard (Xgl) behind closed doors. They have also been developing a new window and composition manager called Combiz. Well, both of these products have now been released into Xorg repositories. So all is well. Is it? There are two issues that this has raised. One is the new wave of standard in-fighting that we are seemingly face. This is because as soon as the community accepted Novell's Xgl (or Xegl - OpenGL version) as the future for X11, Red Hat put the spanner in the works by promoting an alternative: aiglx (accelerated indirect GL X. Red Hat's argument would be sound - both Xgl and Xegl are brand new solutions, which would require a lot of work on the part of driver creators, whereas aiglx is just an extension to the existing X server standard. Hmmm. Here we go again... The other issue that occurred to me is more of the philosophical nature. It refers to the reasoning Novell offered in defense of the 'keep it behind the closed door' approach to the design. The "design by committee" concept is what most companies face, and have to deal with. Novell chose to go against the politically correct community involvement in the early stages of planning, spec'ing and designing. They are being slagged for it, but should they really. For one, I fully agree with Dan Winship's reasoning...

See: http://mail.gnome.org/archives/desktop-devel-list/2006-February/msg00115.html .

Boot from CD - a winner again

Didn't expect to write anything whilst on holidays in Sydney. But couldn't resist sharing my joy of Knoppix saving me from a big row with the hotel staff.

Hotel I'm in is using a third party company to provide telecomms and broadband services. It's awfully expensive, but convenient, so I have subscribed.

So, to get online, you tune into channel 8 on your telly, choose the deal (9.95 for an hour, 44.95 for 3 days), then enter your room number - and bingo, a password is created for you. You connect your laptop and off you go. Except that the socket in our room was faulty. A very friendly manager allowed us to use another room (to test my laptop), using a password he provided for me. It worked (I never doubted my laptop). So, we move rooms altogether. Once moved, tried to connect and the fun started.

Tried the password I had generated before - error message saying - cannot activate: already active. Although the manager's password has expired, I could still connect to the Internet, and use exactly the same sites I did as part of the test, but no others. Tried clearing the browser's cache, reboot, clear the cache again for good measure, same behaviour over and over.

MAC address tied it in? Don't know, but booted from the Knoppix CD, connected the cable, punched in the password - straight in! On the same laptop, with the same hardware.

So, if not a browser's cache, not an interface number, what was it that tied my laptop to the servers information? Am I missing something? Or is the comms provider being naughty and captures more information that I would comfortably want to surrender? I left the question with the manager. Somehow, I don't expect to get any answers before we leave in three days time...

Moral of the story - Knoppix came up trupms again!

Allowing remote X sessions

A couple of posts before, I have described how to use gdmsetup to enable (in conjunction with xhost + command) remote X applications on your machine.

I've been working with our engineers (OK, here goes the mention - Dave Williams, who is fast becoming a Linux expert, and Martin Pain - who, similarly is becoming Oracle and SQL ex if not expert), to update our various course setup documents. The fix for gdmsetup needed to be scripted. A simple trick allowed me to identify the configuration line that needed to be changed:

First save the current setting in a different file:

# cp /etc/X11/gdm/gdm.conf /tmp/x.$$

Then change the setting; run:

# gdmsetup

Select Security tab, and modify the setting for the "Always disallow TCP connections...".

Once done, just compare the two files:

# diff /etc/X11/gdm/gdm.conf /tmp/x.$$
191c191
< disallowtcp="true
---
> DisallowTCP=false

Bobs your uncle. A single line (or two):

sed '/DisallowTCP/s/false/true/' /etc/X11/gdm/gdm.conf > /tmp/x$$
mv /tmp/x$$ /etc/X11/gdm/gdm.conf

placed in an appropriate script, and X applications will now be accepted.

RPM package verification

This post doesn't solve any problems, but is more of a record of the investigation to solve one.

I'm having problems with Fedora Core 4 GUI. Rather unpredictible X behaviour, with not being able to restart it, inability to start just some of the applications, such as xterm or firefox...

Handling X has always been my achilles heal. I resisted windows, of any description ;-), for as long as I could, initially regarding it first as pure waste, then unnecessary nicety. It's only relatively recently that I kind of resigned to the fact that resources are now robust enough to cope, and there exist applications that could not live without GUI.

Anyway, still don't really know what the problem is, but done some googling, and can see that I'm not the only one struggling with this strange GUI behaviour. Somebody suggested verifying X server packages - good idea. Run the rpm --verify on all packages to do with xorg, and got some result:

# rpm -V $(rpm -qa | grep xorg)
. . ? . . . . . c /etc/security/console.apps/xserver
S . 5 . . . . T /usr/X11R6/lib/modules/libvgahw.a

So why post this? Well, mostly to document the result, and to make a record of the file attribute characters.

The eight characters mean differences in:
S - size
M - file type or permissions (mode)
5 - MD5 checksum
D - major/minor device number
L - access path (read-link)
U - user (owner)
G - group
T - mtime stamp (modification time)

Between attribute characters and the file name, the file's type (as in "purpose") may be listed. In my output I got 'c' - a configuration file.


All I know now, that the checksum on the xserver file cannot be verified and that the module archive file has a different size, mtime and checksum (considering what type of file it is - hardly surprising).

So, have I learned anything - not really, but it gave me a chance to experiment with verifying packages ;-)

Working with UNIX 'epoch'

An administrator friend was trying to find out on which date the last change of a password occured. He knew that this information was stored in the /etc/shadow file.

Well, the third field of the shadow file contains a number, which is equivalent to number of days from the epoch, which for UNIX was agreed to be January 1, 1970, at midnight, UTC.

So, let's see how we can convert this information into a meaningful date. For example, on my test machine I have:

$ grep root /etc/shadow
root:$1$.LbW0Bv2$keqd6WlAumjwvqRl2tu6U1:13117:0:120:7:::

The conversion is simpler that you may think - no complicated calculations, just yet another useful option of the date command:

$ date -d "1970-01-01 utc + 13117 days"
Wed Nov 30 00:00:00 GMT 2005

The above command means: show the date based on the given "string". The string used here says: use the epoch as the base date, and add to it the value of the 3rd field (for the user of interest) from the /etc/shadow file .

The unit at the end of the string is important! For example, consider the following:

$ date +%s
1137404710
$ date -d "1970/01/01 utc + 1137404710 sec"

Mon Jan 16 09:46:11 GMT 2006

In the above example we first convert the current date into the 'epoch' value, but expressed in seconds (notice that the +%s formatting is only available on the GNU-enhanced versions of date). We then used the date command to convert this number back into a proper date format.

You could use the output of the date command as part of the string used in the calculations. The following is for illustration purposes only, really. It's a long-winded way of finding the 'now' date.

$ date -d "1970-01-01 utc + $(date +%s) sec"

Mon Jan 16 10:02:54 GMT 2006

Finally, the same -d option can be used for creating any date stamp, for example:

$ date

Mon Jan 16 10:26:21 GMT 2006

$ date -d "+ 30 min"

Mon Jan 16 10:56:42 GMT 2006

$ date -d "+ 2 days"
Mon Jan 18 10:58:03 GMT 2006

xhost in RHEL4

I needed to illustrate how an operator could send an X application from a server to a workstation in his office (I'm talking here RHEL4 boxes).

Simple, done it loads of times - on the workstation do:

# xhost +server-name

On the server run the application from the command line and direct the output to the display on the workstation:

# xapplication -display workstation-name:0.0

WRONG! It's not that simple on RHEL4! Here, you need to enable TCP first, which is done as part of gdm (graghical desktop manager) configuration.

Run:

# gdmsetup

Select Security tab and notice that the following setting is "checked":

"Always disallow TCP connections to X server (disables all remote connections)"

Take the 'tick' off, restart the GUI (CTRL-ALT-Backspace), and all is well - the method shown above will now work.