PC Plus HelpDesk - issue 238

This month, Paul Grosse gives you more insight into some of the topics dealt with in HelpDesk

From the pages of HelpDesk, we look at:

  • Audio CDs and CDROMS;
  • NumLock status, BIOS passwords and keyboards;
  • Trackerballs - high precision mouse;
  • Browser security warnings;
  • Linux User Groups;
  • Better long downloads with wget;
  • Browser-based FTP - 'get'ting;
  • FTP on the command line;
  • UNIX-like-OS file systems; and,
  • Burning CD ISOs with K3b.
 Paul Grosse

HelpDesk

Audio CDs and CDROMS

On some UNIX-like operating systems (some suffer from this and others don't), you might find that you have some trouble ejecting the CD or CDROM from the device using the eject option on a drop-down menu.

As far as reasons go, the main suspect is that the disc in the drive was mounted as an Audio CD and you are using a shortcut that is for a CD ROM (as in the screenshot). CDROMs are block devices (as are other data storage devices such as hard discs and so on) whereas Audio CDs are character devices. If you have a block device in there, you might not be able to unmount it/ eject it by using the eject option on a character device, even though it is on the same piece of hardware.

One solution is, say you already have a link for a CDROM, to have a link for an Audio CD as well (and vice versa).

NumLock status, BIOS passwords and keyboards

On many computer keyboards - especially desktop keyboards - the arrow pad on the right, turns into a number pad when the NumLock light is on. As there is already a set of arrow keys between the right hand set and the normal, qwerty part of the keyboard, it makes sense to have the NumLock set so that it is on when you start the computer up - this being set by the BIOS.

It is also tempting to do the same with a BIOS on laptop. However, this can become a problem if you already have a password set. When you next boot up, you need to type in the password so that the BIOS can recognise it - if you have a keyboard similar to the one on the right, a P will end up as a *, an O as a 6 and so on.

You can overcome this - if you must have the NumLock on on a laptop - by typing a new password for the BIOS. Take the NumLock off to type in your current password, if you need to and then, put the NumLock on to type in your new one. It doesn't matter if you have a password that ends up with numbers in it such as 'killkilo' (which would end up as '25332536') because you can remember it by the keys you press ('killkilo') rather than the numbers that it produces - as long as you don't change keyboards to one that has a different alignment or no overlap at all.

As the number lock on a laptop only has a use if you are typing in large numbers of digit-only sequences, I would recommend that you don't set it on in the BIOS in the first place.

Trackerballs - high precision mouse

The main problem with a mouse is that when you want to click or double-click, you are applying a force to the same device as what you used to position the mouse pointer in the first place. It is inevitable that when you apply the relatively heavy, repeated pressure that is required to double-click, you will move the mouse to some extent because the mouse's job is to measure small movements relative to the surface it is on.

Some people try to squash the mouse hard against the mouse mat but that uses a lot of force and, as a result, can strain your forearm.

The tracker ball on the right (it's so good that I use it all of the time) does a better job for a number of reasons:

  1. The aiming/positioning part of the tracker ball (the ball itself) is separate to the buttons - clicking the buttons does not move the ball at all. In fact, you can pick up the tracker ball or slide it along the desk surface without it altering the position of the mouse cursor. In this way, you can position the mouse, take you thumb off the ball and then do what you have to do with the buttons. This also makes double clicking easier as well.
  2. The whole thing fits well into your right hand - it just rests on it and all of the components are in the correct position.
  3. Moving the mouse cursor around on the screen requires fine motor movements. We have already learned to write at school and have that type of precision in your thumb - here you move the mouse around with your thumb. With a mouse, you use your forearm. Just think what your handwriting would be like if you held the pen stiffly in your fingers (or fist) and used your forearm to produce the motion. Also, by using your thumb, you are not tensing up your forearm by trying to make it do these fine movements - we've already seen that you can move the tracker ball around the desk surface without altering the position of the mouse on the screen.
  4. This type of tracker ball has an optical detection system.
The image on the right is a close-up of the ball. The sensor work in the red/infrared region and therefore to it, it looks like a white ball with black spots on it.

Non-optical mice and trackerballs use little wheels that grip the surface but if your kids have been at the ball with greasy fingers your you have eaten some crisps, you can get grease on this ball without it affecting its performance.

The light sensor doesn't see the grease and it doesn't have little wheels that are trying to grip it - the little dots are detected anyway and your mouse performs normally.

Browser security warnings

There are essentially three situations that warrant warnings on browsers with regard to sending information and the security of the connection.
  1. Sending information in the clear (on http, anybody can read your data if they have a packet sniffer - anybody between your computer and the server)
  2. Switching from http to https (going from in-the-clear to encrypted - https wraps the http data in secure sockets layer (SSL) encryption which uses public key cryptography to exchange session keys and is reasonably secure unless you are using a browser that has been emasculated by US export license restrictions)
  3. Switching from https to http (going back to in-the-clear which would normally not be a problem unless it is a result of bad website design).
You can see in the screenshot what a sample of http network traffic looks like using Ethereal - a network traffic analyser or 'packet sniffer'.

These programs are perfectly legitimate and are very useful if you are trying to make sure that a network is running properly or if you are trying to find out if somebody or something is up to something on your network.

However, they can be used to observe network traffic in order to spy on people so, like everything, it is a double edged sword.

In the screenshot, you can see a packet from Google and this demonstrates just how open http traffic is. If it was https, there would be just a page of gobbledegook.

Closing the door

So, if you want to protect yourself, what can you do without?

If you are just doing some casual browsing using a search engine, you will probably not be bothered about any of the information going in the clear. However, if you are doing online banking, you will want to know that you are using https.

One thing to bear in mind is that some web designers seem to think that you can start off a session using https you can then go over to http and it will be safe. This might have as the reason behind it, the fact that it takes more processing to deal with https so, get them in on https and then, when nobody is noticing anything, switch over to http.

The security of going back to http, as you can see in the screenshot, it totally unfounded as any details in http can be seen - http and https are sessionless - the protocol used for the previous pages have no bearing on the security of the current page.

So, if you never type anything of any value to anybody, you can turn off these warnings. If you do use https, you will need to keep the warning that you are going over to an insecure connection (https to http) simply because you cannot trust the assumption that every web designer has an appropriate understanding of security.

Linux User Groups

If you are thinking of moving over to Linux or you have installed it and need a little help with something then you can contact your local Linux User Group (LUG). There, if it is anything like the one in Derby, you will meet people who have been using it for years and have a knowledge of larger, non-Windows systems as well as complete beginners.

You can find them LUG home page here and a list of regions here. Most LUGs have their own mailing list but the is a list of specialised mailing lists - relating to particular distributions here.

Better long downloads with wget

Downloading a large file just by clicking on a link in a web page is quite simple as long as it works. The problems arise if: the download is particularly large (so it needs to have near-perfect performance over a longer, continuous time); the connection has a lot of contention (there are other people competing for your bandwidth); your machine has to compete with others on the LAN (more crowding of a limited bandwidth); and you have a limited download size per day.

If you are trying ot download an ISO or two (or more) then these large files which are usually around the 600MB size, can seriously eat into your download allowance or at least frustrate you if they fail at some stage (usually towards the end of the download). One other problem is that you might want to download a number of these files - one after the other - and you cannot sit around for hours, clicking on links.

WGET is a program that will download files using a number of protocols, either from the command line or you can use a URL list in a file. It will also, if you want, spider a site, using hyperlinks so that it can download the whole site. It obeys the robots.txt files so shouldn't provide a headache to server admins. You can also control the way it downloads them so that it doesn't clobber a server. Being able to run from a batch file or a crontab/scheduler, if can be made to work automatically so that you can download that large ISO in the early hours of the morning so that the contention is better and there are less users online.

You can get wget (if it didn't come with your system) from here (the main page - http - ftp) or here (the download mirrors page) and if you are running Windows, from here.

When you run wget, it lets you know what is going on and how far it has got. It also keeps a log file if you want so that you can see what has happened if you have been downloading overnight (or if you went to the shops/down the pub or something).

Browser-based FTP - 'get'ting

Most of us have used ftp with a web browser to download files and the anonymous login is handled transparently by the browser. However, if you need to log in on an account that you have, using a UserID and password, you will find that the ftp server is not particularly helpful - usually saying that you have no access rights. This is because you typed in just the IP address or domain name. Non-anonymous ftp needs more than that.

Say that your account name is 'joe90', your password is 'PaperW8' and the IP address is 10.32.19.127. Trying 

ftp://10.32.19.127/

just gives you an error. If you type the UserID, followed by an '@' and then the IP address, ie 

ftp://joe90@10.32.19.127/

you will then be prompted for a password in the same way that you would if you were logging into a password protected http account - the sort of dialogue box you see on the right.

 
Once you are in, the account name will be in the address bar as in the screenshot on the right.

You can also add the password on the address line. Using our example above, it appears like this...

ftp://joe90:PaperW8@10.32.19.127/

However, whilst this is perfectly all right for using automated logons using something like wget where you don't interact with it; and your browser will accept this type of login (ie, without making you type the password into a dialogue box), you might, depending upon the browser you are using, end up with it, along with your UserID, on the address bar after you have logged in (some browsers take the password out when displaying the successful URL).

One thing is certain however, and that is the fact that your password will be remembered by the address bar dropdown list on some browsers. If you click on the down-arrow on the right of the address bar, you will get a list of all of the addresses (including account names) that have been typed in manually. Some browsers also save and display the password.

FTP on the command line

Win98SE ftp client into a Linux box
NetBSD ftp client into a Linux box

Most operating systems have an ftp client. Even Windows 98 has one. As ftp is well established and the client programs work on many platforms, the general command set is pretty much the same.

Essentially, with ftp, you log onto a server, navigate around the viewable file system, upload and download various files and then log off. There are many other things you can do but these are the commands that you will need to use the most. If you want to use others, just look up ftp in the help or manual pages or go online and look it up on the Internet. One other way is to run ftp and type help at the ftp prompt. You will see a list of the commands and their important options. If you type help and the name of the command, you will see its help in detail.

Login

In the screenshots, you can see a typical ftp session (the top one is using the ftp client in Windows 98SE and the bottom one is using the ftp client in NetBSD). On the command line, enter 'ftp'. Next, at the ftp command line ('ftp>'), you need to open the account on the server so you type 'open address' where the address is either the domain name or the IP address of the server you want to contact. In this case, it is a local ftp server at 192.168.1.254. When it has connected, it will give a welcome message and then a error/success code, in this case, 220.

Next, it asks you to log in with your UserID and then your password. If all is well, you will be told that it is. You are now logged in.

Navigation

You can work your way around the file system using the CD command in the same way that you would if you were navigating around a Windows/DOS or UNIX-like system. To go down a level, type 'cd directory' where directory is the name of the directory you want to go to. If you want to go up a level, type 'cd ..'. If you want to go up a level and then back down one, type 'cd ../directory'.

You can see what is in a directory by asking it to list its contents. This is either done with 'ls' or with 'dir'. You can use either on the same system.

You can navigate by typing ls and then cding to the directory you can see. This is sometimes easier than trying to remember full paths and then making a mistake.

One other feature is that you can press the up arrow key and get previous commands.

Uploading

When you upload a file (ie you copy a file from the computer you are on, to the server that you have logged into), you effectively 'put' the file there. So, to put a file, just enter 

put [path/]filename

at the ftp prompt. If it is in the current directory, you can leave out the path. This will copy the file from your machine to the remote one, leaving it in the current directory on that machine, using the same file name that it had on the machie it originated from. You can specify a different name if you want.

Downloading

Downloading is pretty much the same as far as the command line goes. In this case though, you are getting the file so your command line looks like this...

get [path/]filename

which, like put, will keep the file name the same and drop it in the current local directory. Again, you can change the name if you want.

Logging off

To log off, just type 'bye'

If your remote machine doesn't have an ftp server on it but yours does, you can log onto the remote machine using telnet or (better) ssh and then ftp back the the machine you are actually sitting at. However, if you do this, you must remember whether you are getting or putting because you will now be looking at the transfer from teh other side.

UNIX-like-OS file systems

There is much apprehension from people who have had no experience of UNIX-like systems such as Linux, that they will not be able to navigate their way around the file system. suppose the question is 'can you navigate your way around a Windows file system?'

Most of the time, users will just want to stay in their home directory - it has everything there that they need: enough space for their files along with any personal settings and so on.

Also, other users cannot change their files because of the way that the security on the file system works. The only time you need to look at the rest of the system is if you need to do some administration work.

However, knowing what is where can help if you are doing something new.

In the screenshot, you can see a real UNIX-like operating system's file system. This one is from OpenBSD - the others have the same basic directories and structure.
So, here are the main points of interest on the file system
/
 the root directory from which all others are based. There is no C: drive or anything like that, this is better and simpler 
/bin
 This directory contains the executable files (binaries) that you are likely to type in at the command line yourself. eg 'ls', 'grep', 'chmod', 'mail', 'more', 'ps','su', 'vim' and so on. 
/dev
 In this directory, there are all of the devices that are on the system. For example, on some systems, the first hard drive is called 'hda' (the second 'hdb' with 'hdc' being the CDROM, 'hdd' being the next hard drive and so on.

Drives have partitions so the first partition of the first drive is called 'hda1', the second is 'hda2' and so on. So, the path to the second partition of the first drive is '/dev/hda2'

 
/etc
 This directory has the configuration files in it. Unlike the Windows registry, if you mess up a configuration file inhere, only that part of the system won't work. In here you will find some directories for the more complex parts of the system and a number of file ssuch as fstab and so on. 
/home
 
/gecko
/paul
 

/bin
/Desktop
/Documents/Pictures
          /Presentations
          /Spreadsheets
 In the home directory, you will find the directories of the normal users. Each user has a unique ID and that ID is the name of their directory. The directories that are found inside their home depends upon what the user is doing and what programs they are using but you will usually find a /bin directory (for their executable files that are not for other users - they could be writing a program) and if they are using a GUI,a desktop directory ... and so on. 
/mnt
 the mount directory is where devices are mounted from /dev. If, for example, you looked at hda1 - the first partition of the first hard drive, you would see the file allocation table and the clusters of data - assuming that it was a FAT partition.

When file systems are mounted, they are displayed as files and directories.

You don't have to have a file system mounted in /mnt, you can put them anywhere.

 
/root
 This is root's home directory.. Nobody other than root can go in here 
/sbin
 This is where the system binaries are kept. These are the executable biles that you are not very likely to type at the command line. They aare more likely to be called by another system command or by the system when it is going about its normal business. 
/tmp
 /tmp is the temporary directory. This is where files with a short lifespan are kept. Some systems clear this directory out every time the machine is booted and other systems have a routine that is run one a week or so that clears out any files that are older than a certain date. 
/usr
 
/bin
 This is where any user-oriented executable files are kept that are for all of the users - as opposed to the files in /home 
/sbin
 An, this is where the system binaries installed for all users on the system - those not part of the basic system. 
/var
 
/log
 /var covers many types of files but system files such as logs and so on usually go in here. If you are running a web server, some systems will put it into the /var directory.

/var/log contains the log files for the system and some programs have their own log directory in this directory.

 
/spool
 /var/spool contains files such as email files and printer files amongst others.

There are other directories on the main '/' root directory but you wouldn't normally need to concern yourself with these - arguably, you would n;t with most of those above.

In the end, instead of having your home fall under 'Documents and Settings\user' and then some others under a different user with it all being presented as though you are the only user on the system as it does with Windows, you have all of the files you want in your /home/user directory. It couldn't be much simpler than that.

Burning CD ISOs with K3b

Burning a CDR with an ISO on a Linux system is very straight forward. First of all, download your ISOs - if you are burning a free operating system such as Linux or one of the BSDs, you will likely have several ISOs to burn so download them all first - using wget as above possibly. If you have limited space on the machine you are burning them from, download them to another machine on your LAN and then you can transfer them across when you need them - this only takes a few minutes for a 600MB ISO.

With your ISO image in a local directory, just click on the ISO file in Konqueror and K3b should open up and the ISO should be the current file.

If not, select K3b from the menu.

Next, click on 'Tools', 'CD', 'Burn CD Image' - this is in the version of K3b that is with SuSE 9.2. The menu for the version of K3b that is with SuSE 10.0 is very slightly different in that it cuts out a menu stage.

Following this, you select the ISO image you want from the usual load dialogue.
Next, you have some options at the bottom of the form. If you are trying out your CD burning for the first time or are using a storage medium that might be a bit on the slow side, you need to select 'Simulate' Simulate will go through the burning procedure without burning the CD. Whilst this might seem pointless, it is checking that the pipeline between the data storage and the CD will all work throughout the duration of the burn process. If the simulation fails, you need to change something but you haven't sacrificed a CD in the process.

The last checkbox - 'Verify written data' is needed if you are burning an ISO. Whilst the burn process is no different to that without it, if there has been a mistake - even just one bit (as in binary digit) - then this will most likely pick it up.

Finally, Click on the 'Start' button. This is effectively lighting the blue touch paper and retiring to a safe distance.
If you have asked it to simulate the process, it will go through that first and if there are no problems, it will start writing to the disk at the speed it has worked out will work.

This process may take some time depending upon the burn speed and the size of the ISO (This one is for a NetBSD Live ISO at 693.6MB so it is at pretty much the limit of the CD.
Once it has successfully finished the burn (ie, it didn't fail because of any buffers running dry), it then, if you have asked it to, checks the image that it has stored locally. It does this by putting the whole file through an algorithm called MD5.

MD5 will take chunks of data and produce a number. If the data is changed in any way, it will result in a completely different MD5 hash.

When you downloaded the ISO in the first place, there was (or at least should have been) an md5 hash of the ISO on the web site so that you can compare your downloaded image with the one that is on the website. If the md5 hash is different, there has been an error in teh download process. When K3b first loaded your ISO, it started working out an md5 hash and if you weren't too quick at pressing 'Start' it would have displayed the value so you can check the value without first burning the ISO to a CD.
Next, it reads the data off the CD and works out the md5 checksum of that.

If the checksums are equal, it is reasonable to assume that the burning process is a success.

This is why I say reasonable to assume rather than a certainty: An md5 checksum is 32 nybbles long (a nybble is 4 bits and is usually represented by a hexadecimal digit) or 128 bits. So, there is a 1 in 2128 chance that two files will give the same md5 result. To put that into numbers that mean something, that is 3.438 or if you burned an ISO that resulted in a faulty CD, once every 10 minutes, you would on average have to take 6,470,000,000,000,000,000,000,000,000,000,000 years (472,000,000,000,000,000,000,000 times the age of the universe) before you got one that gave the correct ISO but was wrong. Not too bad.

And that is all there is to it.

Back to PC Plus Archive Index Page