Issue #8 June 2005

Tips & Tricks

Red Hat's customer service team receives technical support questions from users all over the world. As they are received, Red Hat technicians add the questions and answers to the Red Hat Knowledgebase on a daily basis. Individuals with a redhat.com login are granted access. Every month, Red Hat Magazine offers a preview into the Red Hat Knowledgebase by highlighting some of the most recent entries.

This month's Tips & Tricks include a sample of questions and answers for system administrators found in the Red Hat Knowledgebase.

Tips from RHCEs

Getting back my GNOME desktop from the clutches of the GNOME configuration system

My problem: as a user I managed to lock myself out of my GNOME desktop though a careless setting of Preferences-> Resolution.

In determining my solution I learned some key lessons about the GNOME configuration system.

My main lesson was that with GNOME you can no longer rely on the time-honored system of editing plain text configuration files. GNOME has its own Windows registry-like configuration scheme.

Another lesson here was that even though the user's default screen settings are simply inherited from the system setting in X, if the user asserts a screen resolution preference, then that preference is kept in the user's own GNOME configuration properties.

In this particular scenario, the solution was to 'unset' the user's screen resolution preferences by first getting a text login and running

gconftool-2 --unset /desktop/gnome/screen/$(hostname)/0/rate
gconftool-2 --unset /desktop/gnome/screen/$(hostname)/0/resolution

Why do init scripts require lock files?

When a service is started through an init script, a file is touched in the /var/lock/subsys/ directory with the same name as the init script. When the service is stopped, this file is removed. The contents of this file are unimportant for the scope of this article, as long as the filename is the same as the init script.

This file represents that a service's subsystem is locked, which means the service should be running. Since a service may consist of multiple executables with different names, finding the process ID (PID) of a single executable may not be sufficient to determine the status of the entire service itself. For this reason, the command:

service <initscript> status
checks both the PID of the executable and the file in the /var/lock/subsys/ directory. If the PID is not found but the subsystem is locked, you will receive a message similar to this:
<service> dead but subsys locked

Managing a service's subsystem has two purposes. First, if the service does not lock the subsystem, it can still be started and stopped through the service interface. However, when switching runlevels, the rc scripts check for the existence of the file in /var/lock/subsys/. If this file is not found, the service will not correctly start or stop between runlevels, even if there are start and kill symbolic links in the /etc/rc#.d/ directories.

Second, the /var/lock/subsys/ directory is checked during reboots and shutdowns. The order of a shutdown is as follows:

  1. Run service <initscript> stop for all known services
  2. Run kill -SIGTERM to terminate all processes
  3. Pause for five seconds
  4. Run kill -SIGKILL to kill all remaining processes

This method of shutting down is ordered such that processes are killed as gracefully as possible. During a shutdown, the script /etc/rc.d/init.d/killall checks the /var/lock/subsys/ directory to see if any subsystems are still locked. If a service's subsystem is locked after all other services have been stopped (i.e. step 1 above has completed), the killall script uses the subsystem filename to call service <initscript> stop. This attempts to stop the service gracefully before handing off to steps 2 through 4, which forcefully terminate the process itself.

Where is the /etc/timezone file in Red Hat® Enterprise Linux®?

The file /etc/timezone is not included in Red Hat Enterprise Linux. The local timezone is stored in /etc/localtime and is used by GNU Library for C (glibc) if the TZ environment variable is not set. This file is either a copy of /usr/share/zoneinfo/ tree or a symbolic link to it.

Note:
The Filesystem Hierarchy Standard (FHS) standard does not mandate the presence of this file or specify its format in Linux. For more information on FHS, refer to http://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/etc.html.

How do I set permissions to Samba shares?

There are many ways to set permissions to your Samba shares and improve security. This tip covers some of the basic permissions.

The most basic settings:

 
read only = Yes
guest ok = Yes

The default is read only = Yes

Share permissions

 
read only:    This parameter controls whether a user has the ability to create or modify files
              within a share.

guest ok:     If this parameter is set to yes, the users have access to the share without
              entering a password. This can pose a security risk.

Example:

[share]
path = /samba
read only = Yes

This option controls write access to the share.

More options

read list:     This option accepts a list of usernames or a group as its value. Users will be given
               read-only access to the share.

write list:    Specifies which users should have write access to the share.

valid users:   You can make a share available to specific users.  Usernames or group names can be
               passed on as its value.

invalid users: Users or groups listed will be denied access to this share.

Example:

 
[share]
path = /samba
write list = user1 user2

Groups

A group name can be added as a value by using two characters before the name:

@ (at symbol)  NIS groups searched
+ (plus sign)  will not search NIS 

Examples:

  
valid users = @groupname
invalid users = +groupname

Create default permissions

create mask:    This option is set using an octal value when setting permissions for files.
                example:   create mask = 1644

directory mask: Directories must have the execute bit for proper access.
                Default parameter is 0755

Example:

 
[global]
create mask = 0775

Notes and additional information

  • UNIX system permissions take precedence over Samba permissions. Proper care has to be taken to set the proper permissions on the directories used for the shares. If a directory does not have write permission, setting Samba permissions to allow writing to a file or directory will not allow an user to write to the share.
  • Permission parameters do not override a file system that has been mounted with specific permissions. If a file system is mounted as read-only, the write ok = Yes parameter will not allow users to write to the file system.

What do "DriveReady SeekComplete Error" messages indicate when seen during the boot sequence?

This error message indicates that the storage device received a request from the Linux kernel that it did not understand and that it is ignoring it. It might, for example, indicate that the kernel driver is issuing multi-mode commands which is not supported by the specific device. This is usually a minor issue and can be ignored without any side effects.

Why do I receive errors like grep: /proc/cmdline: No such file or directory or grep: /proc/mounts: No such file or directory during the boot sequence?

This error indicates that the proc virtual system is not being mounted during system bootup. Linux uses this file system to represent various critical information about the processes to the applications.

If the system does not bootup and provide a login prompt, boot into rescue mode using the instructions in Booting into Rescue Mode.

If you get the error statement:

An error occurred trying to mount all or some of your file systems. 
Some of them may be under /mnt/sysimage

check the file /etc/fstab as it contains the file system table.

Verify whether the proc entry is similar to the one below:

none                    /proc                   proc    defaults        0 0

The directory /proc should exist with read and executable permissions for everyone.

How do I change the shell I use?

The chsh command can be used to change your shell.

There are other options that may be used as well. To check the available shells on your system, use the following command:

chsh --list

which will produce a list similar to:

/bin/sh
/bin/bash
/sbin/nologin
/bin/ash
/bin/bsh
/bin/ksh
/usr/bin/ksh
/usr/bin/pdksh
/bin/tcsh
/bin/csh

To change the shell to csh, use the command:

chsh -s /bin/csh

To verify the current shell, use the command:

echo $SHELL
Note:
The above example is for the root user. Non-root users are prompted for their password before the shell is changed. These changes will take effect on the next login.

This article is protected by the Open Publication License, V1.0 or later. Copyright © 2004 by Red Hat, Inc.