No access to ntp source?

When you install Linux on a PC, you may find that the hardware clock enforced the time. Normally, you would use the ntpd (network time protocol daemon) to synchronise the system (software) time with a selection of external sources.

However, what if you are not connected, or for some reason just don't have access to time servers (for example the ntpd port 123 is blocked)?

Well, unless you need to maintain a precise time (in which case you still need to find access to a reliable source), you can just use the good old date command and inform the hardware clock of the change.

# date --utc 101517052007.00

will update the system (software) clock and set the current time and date to: Oct 15 18:05:00 BST 2007.

The only problem is that system clock doesn't run when your machine is powered off. What does continue to run is the hardware clock. It ticks forever. External power present or not. Because on start-up the hardware clock is used, you need to flush the system date into the hardware clock, and as long as the hardware clock is accurate enough, your newly adjusted time will be persistent over reboots.

Use the hwclock tool to achieve this:

# hwclock --systohc

Do remember, though: this is 'quick and dirty'. If you require consistent and accurate time keeping, you need to synchronise the system clock with an external source...

How much do people pay for Windows software?

There is a discussion brewing in our local LUG, to do with almost philosophical aspect of software theft.
The basis for the thread lie in one of the most interesting articles on the subject I have ever read:

http://tlug.jp/articles/Windows_Is_Free

As many before, it explores moral aspects of using "second hand" software, but less usually, it attempts to analise the implication of cracked software on the industry itself and how, ironically, the effectively free windows software distorts the balance of marketing power between windows, mac OS and linux.

Keyboard layout in Solaris 10

If there is a way of setting UK keyboard during Solaris 10 installation - I don't know it! However, the /boot/solaris/bootenv.rc has a directive for that - just change US to UK.

A reboot, unfortunately is necessary...

Keyboard layout in Centos

I have been playing with Centos 5, which is the community binary for binary version of RHEL 5 (with various elements, such as text and graphics depicting or referring to Red Hat replaced with Centos, quite legally, might I add). It's an excellent alternative, as long as you don't expect a 24/7 support, or automatic updates or any of the value added stuff that a formal contract from Red Hat provides.

Anyway, the install from the DVD onto my Vaio PCG-V505BP went without any problems. Selected "Gnome Desktop", "Server" and "Server-GUI" software, and the only other customisation was disk partitioning (I like my partitions to be done the old-fashioned UNIX style).

So, as I said, the installation completed successfully, and to my best knowledge all hardware was recognised OK (still testing, so can't be totally sure). One little surprise, though - the keyboard layout was the US, not UK! Well, it is quite possible that I messed it up myself (when selecting the keyboard during installation). Either way, I went to correct it by hand, and thought I'd document it. It's quite straightforward, but a thing to remember is that two different configuration files need to be changed.

For CLI (character interface screen, accessed through CTRL-ALT-F1 - F6) you need to modify the /etc/sysconfig/keyboard. Change the KEYTABLE line to read:

KEYTABLE="uk"

This will have immediate effect, and any new CLI session will assume the correct keyboard.

For GUI screen terminals, you need to change the Xorg configuration file: /etc/X11/xorg.conf. In the "Section InputDevice", identify the line with XkbLayout and modify it to read:

Option "XkbLayout" "uk"

Unlike CLI setting, this GUI change will only take place after GUI session is restarted. I have tried the standard CTRL-ALT-Backspace, to restart Xorg server, but it didn't work! Well, not for the first time. On many systems this is disabled.

I refuse doing a full reboots lightly, so I tend to 'recycle' GUI instead. First of all, make sure you don't have any GUI-dependent users or applications before you carry out the next step (they may not like being kicked off the system without a warning).

To 'recycle' GUI means switching runlevels to 3 than to 5 again. To do that: open a CLI session (press CTRL-ALT-F1), log in as root, and switch runlevel to 3 with:

# init 3

Once the 'anaconda' message appears on the screen - you are in runlevel 3, even though you see no new prompt. Hit "Enter", and the prompt will be printed. At that point, switch back into runlevel 5 with:

# init 5

Your new keyboard layout is now available to all users.

Default gateway in Solaris 10

I'm spending a lot of time switching between different versions of UNIX and Linux, and the detailed syntax of the command line stuff keeps catching me out. So I will start documenting for myself (and any QA-IQ colleagues) some of the most popular things that are needed in our classrooms.

This week it is a turn of Solaris 10 (ix86), in our Swindon office. Our infrastructure is such that the 192.168.1.254 gateway requires an argument of 1 where the 'metric' value used to be. No rocket science - just the command line syntax, but it kept me unconnected for far too long (or am I getting too indoctrinated by the Linux syntax and the power of the ip command there?).

Anyway: to add the default gateway to the Solaris 10 :

# route add default 192.168.1.254 1

Then obviously adjust the browser settings to the correct proxy for your location (with port 8080 on QA-IQ sites). In the Mozilla version provided with Solaris 10 you can find the settings in Edit --> Preferences --> Advanced --> Proxies.

Get it back together again

Had so many changes within the company - blog went onto the back burner. Things are getting calmer and easier again, and hopefully I can get on with it properly. With any luck, the postings will start coming out again...

Forcing hp2400 to print double sided

Needed to print a set of labs for a new version of a course. Run out of time, and although the manuals are being printed, the labs documents had to be done by hand! So to save the Amazon, I managed to get my printer to print double-sided! Although this is specifically for the hp2400, the algorythm of printing sequence and which way at which stage should be useful for any printer...

1. Ensure all documents have an even number of pages

2. First print the even pages with the last page on top.

Select File --> Print...

- in "Print:" drop down menu select "Even pages" (default is "All pages in range")

Then select "Properties" --> Basics

- in "Page Order" mark "Back to Front"

Then press "OK" in Properties screen, and "OK" again in Print screen

3. Replace the paper

Pick up the freshly printed pages. Keep them together, in the same order they were printed and the same side up (i.e. printed side up). Rotate the whole bunch 180 degrees horizontally and insert in into the paper tray. Once in the paper tray, the orientation of the paper should be such that one can read the pages correctly, with the highest even page at the top.

4. Print the odd pages with the ultimate result having the first page on top.

Select File --> Print...

- in "Print:" drop down menu select "Odd pages" (default is "All pages in range")

Then select "Properties" --> Basics

- in "Page Order" mark "Front to Back"

Then press "OK" in Properties screen, and "OK" again in Print screen

The IFS mystery

The IFS is involved in the parsing of the command line (word splitting) and in variable assignment during the read built-in execution.

But there is a side effect, which I have only discovered recently, by accident. If you assign positional parameters with set:

$ set a 'b c' d 'e f'

than using the * parameter we can get at the values individually or as one word. To illustrate, try the following:

$ echo $* "$*"

a b c d e f a b c d e f


However, if you 'nullify' the IFS variable:

$ IFS=""

then the behaviour of the shell when referencing the * parameter changes:

$ echo $* "$*"

a b c d e f ab cde f

This only works with the * parameter (not with @) and only if IFS had a null value (if you inset IFS altogether, then the shell will use a space to separate positional parameters.

Finally, I've checked this behaviour in ksh and bash - same (and documented in manual pages, at least in bash).

Quoting command substitution

When we learn the inner works of a shell, we quickly realise the benefit of using double quotes with request for variable substitution.

For example, to assign a value to a variable (and preserve leading spaces), we would use:

$ address=" 23 Acacia Avenue "

A correct quotation is needed to recall the value complete with the spaces:

$ echo "<$address>"

The less known application of the quotes is when they are around the command substitution syntax. By default, POSIX shells remove trailing new-lines during command substitution. Double quotes change this behaviour!

Compare the output of the following commands:

$ echo $(ls)
log.1 log.2 log.3

and

$ echo "$(ls)"
log.1
log.2
log.3

Graphics problems...

For all its maturity, problems with graphics with installs out of the box are still there... This time, trying to use RHEL4 on an HP machine with Intel 82845G/GL[Brookdale-G]/GE Chipset.


Seems fine, until you try to restart the X Window System with CTL-ALT-Backspace. The screen just goes blank, no message, no GUI - nothing. Log into a character interface, run level 5 is shown, and the startx command works well.


Just wonder, actually... Could it be a setting somewhere stopping the CTL-ALT-Backspace restart deliberately? Will need to do a bit of 'googling'.

Adjusting the kernel for Oracle

In the golden old days, when installing Oracle on UNIX, a laborious kernel recompilation process was often needed, to adjust required memory parameters.

On Linux, the process is much simpler, as most of the significant parameters may be changed 'on the fly', effortlessly, and without as much as a reboot, let alone kernel compilation.

All current kernel parameters may be found in /proc/sys/kernel location. Explore it, to see that each parameter has its own file, with either a Boolean Yes/No (or 1/0) or a string value.

The set of parameters required for Oracle10g (only part of the list is quoted here) says:

shmmax  = 2147483648
shmmni  = 4096
shmall  = 2097152
shmmin  = 1
shmseg  = 10             

There are different ways of implementing it: first of all, you can get the values directly into the memory constructs, for example:

# echo 2147483648 > /proc/sys/kernel/shmmax

This will adjust the value correctly, with the slight drawback - the value will return to whatever the default was after the next reboot.

Alternatively, for a more permanent modification, you can place the required definitions in the kernel configuration file: /etc/sysctl.conf.

kernel.shmmax=2147483648
kernel.smni=4096
kernel.shmall=2097152
kernel.shmin=1
kernel.shmseg=10

and inform the kernel of the changes with:

# sysctl -p

command, which will read the values from the sysctl.conf file and place them in the
appropriate files under /proc/sys/kernel.
Any subsequent reboots will also make use of these values.

Crashing Unix?

What's that?

Having now worked so much with Linux, I have developed an unhealthy approach to file system care. Initially by accident, then by design - to test, now by habit, when I shut a Linux machine, I just slam the lid - generally just pull the power on it (I'm talking laptops here - not really advisible on servers, especially of a production, live variety).

Well, I've been waiting for some kind of corruption, longing for the fsck to be forced on me, waiting to sit there for the entire afternoon typing "yes", because I've forgotten to provide the -y option (and worrying that ^C would upset it further - which it wouldn't!).

Nothing! A bit of a delay on subsequent boots, but no disaster of any description.

This week we are working on porting our generic UNIX admin course onto SPARCs with Solaris 9 (I'm still not up to speed with the new Solaris 10 features, but that's a totally different story).

We are working at the brand new offices in Birmingham (on the verge of the China Town - wonderful, but that's yet another different story). The machines were shipped from London. Once connected - power on, and... three out of four boxes booted OK, the last one would not.

Guess what: had to do a manual fsck on the /var partition. Guess what: forgot to do the -y option. Except that I did interrupt it this time ;-)

Fsck declared the partition healthy - boot into runlevel 3 - no joy: utmpx file missing. Back to single user: it turned out that most of the /var partition is missing! Having recreated most of it by hand, the machine came up - eventually.

Now then - I might be totally unfair to Solaris at this point, but the corruption has no known history or explanation. The machines had been installed at the same time from a jumpstart (logs confirm it), then they were shutdown and shipped. Did the engineer pull the power? Very likely. Did the engineer remove by hand some of the /var tree - doubt it very much.

Well, at least I had a chance to reacquaint myself with the good old fsck !

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 ;-)