Privacy and Security Notice

CC Home | JLAB Home | JLAB Internal

Helpdesk | Services | Scientific Computing | Networks | Telecommunications | CAD/CAE | Policies

JLab Linux Installation FAQ

JLab Linux FAQ

This page contains answers to many common questions our users have about using Linux at JLab, organized loosely by topic.  It's not a general Linux FAQ.  It concentrates on JLab-specific issues that our Linux users and administrators might run into.  For more general Linux help, try The Linux FAQ maintained by the Linux Documentation Project.

If you would like to suggest an entry for this FAQ, please contact the helpdesk at x7155.

0.0:   Table of Contents

1.0:   Installation Questions

1.1:    What versions of Linux does JLab support?

The Lab supports Red Hat Enterprise Linux 3WS (RHEL3).  The "WS" part means that this is a workstation version, though it is suitable for many server uses as well, including HTTP, FTP and Samba.

1.2:    I don't want the officially supported version.  Can I use something else?

You are free to use any version of Linux that you like, but you must realize that when you run into problems with it, you're going to be working through them on your own.  The Computer Center isn't staffed to offer support for other arbitrary versions of Linux. 

You'll also be responsible for performing the configuration tasks the Lab's IT policy requires for all Linux machines, as well as configuring other optional settings to make your system work better in the Lab's
environment. 

1.3:    Where do I get Linux, and how do I install it?

The Computer Center distributes the supported versions of Linux.  You can get installation CDROMs for building Level 1, Level 2 or standalone from the helpdesk.

As for installing Linux, the Computer Center maintains detailed Linux installation instructions here.

1.4:    I already have Linux installed, and I just want to upgrade to the latest version.  Can I do that?

We very much wish that this were possible, but it is not.  Red Hat supplies no upgrade paths from any previous Linux version to RHEL.  You'll need to do a full installation to get the latest version, though we have reason to hope that this may change when you upgrade between different RHEL versions.

1.5:    My computer already has a hostname and network address assigned to it.  How can I find out what they are?

If the computer already runs Linux:
You can use either the /bin/hostname or the /bin/uname -n commands to determine your hostname, like so:

	% /bin/hostname
	myhost.jlab.org
Finding the network address (also called the IP address) is a little more tricky, but not much.  The tricky part is that your computer can have more than one IP address sometimes, usually if you have more than one network card connected (a wired and a wireless card, for example). 

Each network card has a specific name, usually something like eth0 or eth1.  You can use the /sbin/ifconfig command to print a list of all your network cards and their settings, like so (the address is highlighted):

	% /sbin/ifconfig

	eth0      Link encap:Ethernet  HWaddr 00:41:05:CF:D7:EE
	          inet addr:192.168.3.4  Bcast:129.57.43.255  Mask:255.255.252.0
	          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
	          RX packets:1126715 errors:0 dropped:0 overruns:1 frame:0
	          TX packets:741245 errors:0 dropped:0 overruns:0 carrier:0
	          collisions:0 txqueuelen:1000
	          RX bytes:653118031 (622.8 Mb)  TX bytes:291621007 (278.1 Mb)
	          Interrupt:5 Base address:0x9000
	lo        Link encap:Local Loopback
	          inet addr:127.0.0.1  Mask:255.0.0.0
	          UP LOOPBACK RUNNING  MTU:16436  Metric:1
	          RX packets:54488 errors:0 dropped:0 overruns:0 frame:0
	          TX packets:54488 errors:0 dropped:0 overruns:0 carrier:0
	          collisions:0 txqueuelen:0
	          RX bytes:3482796 (3.3 Mb)  TX bytes:3482796 (3.3 Mb)
 In this case, the system has one main interface (eth0), with an IP address of 192.168.3.4.  You can usually ignore any interface whose name doesn't begin with "eth".  If you see more than one "eth" entry listed, you should usually use the card called "eth0" to install your Linux computer.

If the computer runs Windows 2000/XP:

[This hasn't been written yet, but contributions are welcome!]

1.6:    How do I set my computer to boot from the CDROM drive?

This varies widely depending on who made your PC and what model it is.  Many computers are configured this way already, so you stand a good chance of "just having it work" if you simply try to boot from the CDROM drive. 

If your PC isn't already set up to boot from a CD, you will probably have to modify the BIOS settings to change the boot device priority.  Most PCs show some kind of message when they start up telling you how to get into the "SETUP" screen.  Usually you have to press F1, F2 or DEL before the OS starts booting.

Some computers allow you to temporarily set the boot device for this session without entering the BIOS setup screen.  This capability doesn't exist on all computers, but it can be handy.  For example, on an IBM ThinkPad T20 laptop, you can press F12 while the IBM logo is still showing, and this will bring you to a boot device menu you can use to start the computer.

1.7:    I already have Windows installed and need to make space on my hard drive for Linux.  How can I resize my existing partitions without losing all my data?

The Computer Center doesn't support this, and certainly doesn't recommend it.  You'll need to use a program like Partition Magic or QtPartEd to repartition your hard drive.  This is an advanced procedure, and if you make even a single mistake, you are likely to lose all the data on your entire hard drive, even on partitions you didn't think you were modifying. 

If we haven't scared you away, and you still want to try repartitioning your drive, you should prepare a space of at least 10GB for Linux. 
1.9:    I need some place to make temporary backups of important files while I install Linux on my machine.  Where can I put them? The Computer Center provides large temporary storage for files and directories, and you can use this facility to store your backups temporarily.  This "scratch space" area is cleaned up periodically, and files older than 14 days will be automatically deleted, so this isn't suitable for long-term storage, but is just what you need for storing backups while you're building your new Linux system.

If your machine runs Windows, you can access your individual scratch directory directly, by pointing to Start->Run and typing "\\jlabscr" into the dialog box.  This will bring up an Explorer window in your scratch directory, and you can drag-and-drop files into this area to save them on the central servers.

On most Linux machines, the scratch disk is mounted as /scratch (or sometimes /u/scratch).  Each user has their own subdirectory under /scratch, so if (for example) your login name is jsmith, your scratch directory would be /scratch/jsmith. 

Standalone Linux machines may not have the scratch disk mounted, so you may need to transfer your data over to a Level 1 or Level 2 machine first, and then copy it to /scratch.  The machine jlabl1.jlab.org would make a good choice for this, but really any Level 1 or Level 2 machine you have access to will do. 

If you don't already have /scratch mounted, you can attempt to mount the scratch area on your Linux machine manually, which might be easier than copying voluminous amounts of data to one of the central machines.  This is usually easy, but you'll need to be logged in as "root" in order to do this.  The commands below show how to create and mount the /scratch directory, as well as how to copy files to it and then unmount it when you're done:
	# mkdir /scratch
	# mount jlabscr:/scratch /scratch
	# ls /scratch
	[This will produce a lot of output, so you know it worked]
	# cd /scratch/george
	[To access your personal scratch directory, use your own username]
	# cp -rp /home/george /scratch/george
	# umount /scratch

1.10:  I have an Athlon 64 system (or one with some other AMD64, IA-32e or x86_64 compatible CPU).  Does the Computer Center offer 64-bit Linux systems?

At this time, the answer is "no".  We do not have 64 bit machines of our own on which to test the builds, and they weren't working right for any of our users, so we have been forced to discontinue support for them.  We apologize for any inconvenience, and hope to be able to support these again in the future.

1.11: I see the Computer Center updated to RHEL Update 2 (or 3, or 4, or ...).  What's the difference?

Every 3 months, RedHat puts out an Enterprise Linux update that includes all the latest patches into the default installation.  It usually also includes updated drivers to support installing Linux on new hardware that wasn't available when the original version was released.

Although the Computer Center Level 1 and Level 2 builds automatically incorporate the latest patches while the system is being configured, it takes time to first install the OS, then go back through and load all the latest patches.  The updates actually fold the patches into the OS installation, so there are far fewer patches to install during configuration.  This can save as much as 30 minutes or more when you create a new Level 1 or Level 2 system, but in the end, you still get exactly the same system and patches.

Note: Whenever a new update comes out, the Computer Center also issues a new boot CDROM.  Previous versions will no longer work, and you must either obtain a new one from the helpdesk or download this image and burn one yourself.


2.0:   Using Linux at JLab


2.1:  I can't find Ghostview under
Enterprise Linux.  Where is it?

Ghostview is an application for viewing Postscript files under
Unix.  Red Hat removed the standard Ghostview application from
their Enterprise Linux product, but has replaced it with a GNOME
desktop version (which should also run under KDE, and perhaps under
other window managers as well).  If you have the ggv package installed, the command
will be available as /usr/bin/ggv. 
If you don't have the package and you are using a standalone Linux
system, you can install it from our Red Hat Network Satellite server by
executing this command as root: up2date
ggv.  



Of course, if you are using a Level 1 or Level 2 CUE Linux workstation,
the original version is also available as /apps/bin/gv, so you can decide for
yourself which version you prefer to use.


3.0:   Administering
Linux at JLab




3.1:   Grep runs very slowly,
encryption-related Perl modules won't compile or run, or acroread
refuses to render some PDF files.  What's up with this, and how
are these related?

This is a weird problem, but fortunately there is often a simple
solution.  Linux uses a "locale" setting to determine
international localization settings (currency symbols, number
formatting, preferred language, etc).  RHEL is set to the default
of "en_US.UTF-8".  UTF-8 is a multibyte character encoding scheme
related to Unicode.  In theory, UTF-8 would be an excellent choice
for a locale, but in practice the Red Hat implementation has proved to
be somewhat poor. 



Changing the locale from "US English with UTF-8 encoding" to simply "US
English" (or whatever your preferred language is)  is probably the
best thing to do for now.  To do this, edit the /etc/sysconfig/i18n file and change
it from this:




	LANG="en_US.UTF-8"
	SUPPORTED="en_US.UTF-8:en_US:en"
	SYSFONT="latarcyrheb-sun16"



to this:




	LANG="en_US"
	SUPPORTED="en_US.UTF-8:en_US:en"
	SYSFONT="latarcyrheb-sun16"

You will need to reboot your machine for this change to take affect
globally. 


3.2:  I'm missing some include files
or libraries I need to compile with.  Aren't they part of
Enterprise Linux?

It's hard to say, but if it's a common package (X11, OpenSSL, LDAP,
etc) the odds are good that it's available as an RPM.  If not,
then you probably need to go find the software's home site then
download, compile and install it yourself, either in your home
directory or (if you have a standalone machine) in /usr or
/usr/local.  



If the package is part of Enterprise Linux, you're in luck.  It
probably just means you didn't install the developer's packages for the
application.  Many programming libraries install only their
runtime components by default, and rely on the administrator to install
their developer's package if it's needed.  For example, Enterprise
Linux uses the OpenSSL library to provide SSL support to web browsers,
email clients and other network programs that need to encrypt data for
transmission.  By default, the installer includes the openssl RPM on a new system. 
However, if you want to compile new programs that use SSL, you'll also
need to install the openssl-devel
RPM, which contains header files for the C compiler.



Some of the more common -devel
RPMs are listed below:


Once you know the name of the package you need, you can usually just
run "up2date <packagename>" as root to install it from our Red
Hat Network Satellite server (e.g., "up2date
openssl-devel").


3.3:  I just installed Enterprise
Linux.  How will this machine be
kept up-to-date with the latest security patches and bugfixes?

If you have a Level 1 or Level 2 system, your machine will
automatically be kept up to date with all the latest patches. 
Administrators of standalone Linux machines should follow the
instructions in the document entitled "Required
Configuration Tasks for all JLab Linux Computers" in order to
configure their machine(s) for patching.  



The Computer Center manages patches for all Enterprise Linux machines
according to the following guidelines:


    
  
  1. Important security patches are usually applied as soon as they
are available and have been tested by the Computer Center
    
  
    2. 
  
  2. Non-critical security patches and general bugfixes are usually
applied during the Computer Center's monthly maintenance windows, as
advertised at http://cc.jlab.org/,
though they may also be applied before then if there are important
security patches (see #1) which need to be applied.
    3. 
  
  3. Kernel patches will usually not
be applied, unless they contain security fixes or solve a specific
problem the system is experiencing.  
    4. 



3.4:  But I want to manage my
own patches!  What can I do?

This is possible, but in most cases we discourage it.  A typical
week usually sees several new patches become available, and who has the
time to evaluate them all, test them and make sure they get applied
properly?  It's usually much more productive to allow the Computer
Center to manage this process centrally; we can do everything once and
then apply the patches en masse
to all the Linux systems here at the lab.  Having many
administrators evaluate, test and install each patch is much less
efficient.



Having said that, there are still some systems for which central patch
management is not appropriate.  Machines that run mission-critical
services should probably be managed by someone who is more intimately
familiar with their operation and scheduling.  Data acquisition
machines are a good example, since downtime translates directly into
lost data, which probably can't be recreated.  If your machine
falls into this category, the Computer Center can create an account for
you on our Red Hat Network Satellite server, so you can directly manage
the patches for your machine(s).  We'll still see the status, and
you can expect to be contacted if you fall too far behind in your
patching duties, but for some systems this is the best way to
patch.  If you need to take advantage of this service, contact the
helpdesk.


3.5:  How do I patch my system
manually?

This is pretty easy.  You can apply all the most current patches
with a single command.  Just run the following as root: "up2date
-uif".  This will update your computer with all the latest RHEL
patches.  Although it is usually not necessary to reboot after
this, you may wish to do so if there were a lot of patches applied, or
if the glibc or kernel packages were updated. 




For those of you who would like to update to the newest patches without updating the kernel, you can
use the following command (again, as root): "up2date -ui".  Note
that this is the same command as above, without the "-f" option. 
"-f" instructs the system to install any patches which it would
normally skip, and the default skiplist is limited to packages with
"kernel" in their name.  There's no need to update to each kernel
release as it comes out, but you should update kernel packages whenever
there is a security fix.


3.6:  /lib/libdb.so.3 seems to be
missing on my system.  Where do I find it?

This library is part of the compat-db
package, which provides backwards compatibility with older versions of
the Berkeley DB database format.  You can install it by issuing
the following command as root: up2date
compat-db.


4.0:   Other Questions

No questions have been submitted for this section yet.  If you
would
like to suggest an entry for this section, please contact the helpdesk at x7155.




        
                

                        This document is maintained by
                        
                                {helpdesk@jlab.org}
                        
                

                

                        Copyright Jefferson Lab 2007