ProductsDesktop Server For Scientific Computing For IBM POWER For IBM System z For SAP Business Applications Red Hat Network Satellite ManagementExtended Update Support High Availability High Performance Network Load Balancer Resilient Storage Scalable File System Smart Management Extended Lifecycle SupportWeb Server Developer Studio Portfolio Edition JBoss Operations Network FuseSource Integration Products Web Framework Kit Application Platform Data Grid Portal Platform SOA Platform Business Rules Management System (BRMS) Data Services Platform Messaging JBoss Community or JBoss enterprise
SolutionsApplication development Business process management Enterprise application integration Interoperability Operational efficiency Security VirtualizationMigrate to Red Hat Enterprise Linux Systems management Upgrading to Red Hat Enterprise Linux JBoss Enterprise Middleware IBM AIX to Red Hat Enterprise Linux HP-UX to Red Hat Enterprise Linux Solaris to Red Hat Enterprise Linux UNIX to Red Hat Enterprise Linux Start a conversation with Red Hat Migration services
TrainingPopular and new courses JBoss Middleware Administration curriculum Core System Administration curriculum JBoss Middleware Development curriculum Advanced System Administration curriculum Linux Development curriculum Cloud Computing and Virtualization curriculum
ConsultingStandard Operating Environment (SOE) Strategic Migration Planning Service-oriented architecture (SOA) Enterprise Data Solutions Business Process Management
Issue #8 June 2005
- Meet Fedora Core 4
- Fedora Extras: Everything but the kitchen sink
- Now open: Red Hat Directory Server and Fedora Directory Server
- Video: Open source is inevitable
- Sharing photographs online
- Despite opposition, truth happens
- Creating desktop profiles with Sabayon
- Choosing an I/O Scheduler for Red Hat Enterprise Linux 4 and the 2.6 Kernel
- Red Hat GFS vs. NFS: Improving performance and scalability
- Migrating from Solaris
- See what turns our page
- Video: Customer speaks out
- Red Hat GFS: Combining Fibre Channel and Gigabit Ethernet
- Visionaries honored with Red Hat Summit Awards
From the Inside
In each Issue
- Editor's blog
- Red Hat speaks
- Ask Shadowman
- Tips & tricks
- Fedora status report
- Magazine archive
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
by Richard Keech, RHCE
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?
by Bradford Hinson
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> statuschecks 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
/var/lock/subsys/ directory is checked during reboots and shutdowns. The order of a shutdown is as follows:
service <initscript> stopfor all known services
kill -SIGTERMto terminate all processes
- Pause for five seconds
kill -SIGKILLto 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®?
by Rahul Sundaram
/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.
- 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?
by Robert Munilla
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
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.
[share] path = /samba read only = Yes
This option controls write access to the share.
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.
[share] path = /samba write list = user1 user2
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
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
[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 = Yesparameter will not allow users to write to the file system.
What do "DriveReady SeekComplete Error" messages indicate when seen during the boot sequence?
by Rahul Sundaram
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?
by Rahul Sundaram
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
/proc should exist with read and executable permissions for everyone.
How do I change the shell I use?
by Michael Kearey
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:
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:
- 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.