Wednesday, August 15. 2007
The bash man page says that .bash_profile is executed by login shells. But I log into my desktop using gdm. So I'm confused at what point is .bash_profile executed. Or is it? If it isn't, where should I define environment variables?
The answer to this question lies in the difference between a login and a session. A login occurs when you authenticate to the system in character mode
Fields in this file are separated by colons (":"), and the seventh field contains the name of the shell that will be executed upon login. This doesn't have to be a shell in the traditional command-interpreter sense; it can be any valid program, and it's not uncommon to use a menu program or a specific application (such as an e-mail program) for the convenience of inexperienced users or to constrain what the user can do. If the user should not be permitted to login at all, the program /sbin/nologin is specified as the shell, which simply prints the message "This account is currently not available" and exits (tip: you can create a custom message in the file /etc/nologin.txt).
The normal value for the login shell field on a Fedora system is /bin/bash, the Bourne-again shell (a nameplay on the Bourne shell, one of the first and most popular Unix shells). Like other shells, bash executes a startup script every time a shell starts (~/.bashrc) and two profile scripts at each login (/etc/profile and one of ~/.bash_profile, ~/.bash_login, or ~/.profile -- Fedora sets up new accounts with ~/.bash_profile by default). Note the difference: if you login once and then start three shells, /etc/profile and ~/.bash_profile will each be executed once, but ~/.bashrc will be executed three times.
A session, on the other hand, is the graphical version of a login. The session is started by the display manager gdm (or, alternatively, kdm or xdm) when the program starts. The session is under the control of a session manager, which starts standard clients (GUI programs), re-starts certain clients if they die, and optionally restarts clients that were open when the last session ended. The GNOME session manager is gnome-session and the KDE session manager is ksmserver, which is started by the startkde script. This process completely ignores the seventh field in /etc/passwd, and the login profiles are not executed.
But it's not quite that simple: the session manager is started by the script /etc/X11/xdm/Xsession, and in Fedora, that script does not execute the session manager directly. When starting a GNOME session, it executes this command:
And for a KDE session it executes:
The environment variables used in these commands are set by the script /etc/X11/xinit/xinitrc-common. Usually, SHELL is /bin/bash, SSH_AGENT is /usr/bin/ssh-agent, and DBUS_LAUNCH is "/usr/bin/dbus-launch --exit-with-session".
Together, this means that bash is run as a login shell and therefore executes /etc/profile and ~/.bash_profile. It then starts ssh_agent, which then starts dbus-launch, which then starts the session manager. This chain ensures that environment variables set by the login profiles, ssh_agent, and dbus-launch programs are properly exported to the programs running within the session.
We can easily test this execution path by adding some code to the end of the ~/.bash_profile:
If we now login in character mode, we see these messages:
Notice that the message ".bash_profile executed" from the echo command is displayed correctly, but that zenity can't display its graphical message because there is no X server available. On the other hand, when we login graphically, the zenity dialog shown in the screenshot is displayed, but the output from echo is not visible (note that since there is no window manager running, the zenity window does not have window decorations such as a border, titlebar, or controls). Regardless of how we've logged in, if we check the environment variable FDP, we find that it has been correctly propagated:
So you can safely export environment variables from your .bash_profile in all cases.
However, if the profile needs to interact with the user, it should detect whether it is running in a character-mode or a GUI environment. If in a character-mode environment, the command tty will return success; if in a GUI environment, the DISPLAY variable should be set. To ask the user a question, you could use code such as this:
In addition to the profiles executed at login and the ~/.bashrc script executed when a shell starts, the ~/.bash_logout script is executed when the user logs out. The Fedora default logout script simply clears the character-mode screen, ensuring that no confidential information is left visible.
Wednesday, August 8. 2007
Fast User Switching enables more than one user to log in to a local graphical user interface on a computer equipped with a single seat (monitor/mouse/keyboard) and permits quick switching between logged-in users.
Under Gnome on Fedora, the fast user switching agent applet on the panel bar provides access to FUS; under KDE, use the Switch User option on the K Menu. In either case, you'll have the option to switch to an existing session or to start a new session.
You can invoke an additional login from the command line using the gdmflexiserver command. If Xnest is installed, you can also invoke a new session on an Xnest display using the -n option. The chvt command enables you to switch virtual terminals.
Fast User Switching takes capabilities that have existed for years in the Linux kernel and X Window System and makes them readily available and easy to use.
Fedora Wiki page on Fast User Switching (pre-F7 discussion): http://fedoraproject.org/wiki/Desktop/FastUserSwitching
Wednesday, August 1. 2007
By default, the Fedora ls command colour-codes file listings when they are displayed on a virtual terminal or terminal window, but not when they are piped into another command. For example:
Notice that cbq, console, modules, networking, network-scripts and vdr-plugins.d are all in blue (indicating a directory); libvirtd and xendomains are in green (indicating an executable file); and selinux is in turquoise (indicating a valid symbolic link).
The ls output is in colour because ls is actually an alias:
When ls is executed, the option --color=tty is automatically added (note to those in Commonwealth countries: color option has no u here!).
The actual colour associations are contained in the environment variable LS_COLORS, which is set by the script /etc/profile.d/colorls.sh (or colorls.csh if you use csh). This script, which is also responsible for setting up the ls alias, gets the colors from one of several possible configuration files; these are from highest to lowest priority: ~/.dir_colors.$TERM, ~/.dir_colors, ~/.dircolors.$TERM, ~/.dircolors, /etc/DIR_COLORS.$TERM, or /etc/DIR_COLORS (where $TERM is your current terminal type as specified by the TERM environment variable).
All that to say that unless you've customized your system, your ls colours are specified in /etc/DIR_COLORS.xterm and /etc/DIR_COLORS, depending on whether you're using an xterm-compatible terminal window or a virtual console.
The /etc/DIR_COLORS.xterm file contains these lines:
As you can see, each file type or extension is matched up with a corresponding list of attributes and colors to be used. The color and attribute codes are listed in the comments within this file.
You can easily make a personal copy of this file and modify it to suit your needs:
If you wanted to show .doc files in white-on-magenta, for example, add this line to ~/.dir_colors.xterm:
Since 01 is the attribute code for bold, 37 is a white foreground, and 45 is a magenta background.
Wednesday, July 25. 2007
The /var/log directory contains a number of different log files. Many of these logs are generated by syslogd, which accepts log messages from programs and routes them to log files, the screen, and remote log monitors.
The file /etc/syslog.conf configures message routing. This is the file as shipped in Fedora 7:
# Log all kernel messages to the console.
This file consists of comment lines, which start with #, and routing lines, which consist of a message specification and a destination. The message specification consists of one or more selectors, which specify a pattern of facilities and levels separated by a period.
The facility indicates the origin of the log entry. Possible values are authpriv, cron, daemon, ftp, kern, local0 through local7, lpr, mail, news, syslog, user, and uucp. The level is a priority value and may be (in order of increasing severity) debug, info, notice, warning, err, crit, alert, or emerg.
In selectors, a level written by itself selects messages of that level or highers, a level preceeded by an equal sign indicates messages only of that level, a prepended exclaimation mark means "not", and an asterisk matches anything. The dummy level none is equivalent to !* and is used to prevent all matches with a particular facility. A semi-colon is used to AND multiple selectors, and a comma is used to OR facilities or levels within a selector.
Interpreting the default syslog.conf file, we see that all messages of info level and higher except those from the mail, authpriv (authentication), and cron systems are placed into /var/log/messages. Messages from authpriv are placed in /var/log/secure (because they may reveal sensitive information and require more restrictive read permissions on the log file), messages from mail are placed in /var/log/maillog (the leading - indicates that the file's buffers are not flushed after each write), and messages from cron are placed in /var/log/cron. Emergency (and higher) messages are written to all open terminals (*), critical messages from uucp and news are additionally placed in /var/log/spooler, and boot messages (local7) are placed in /var/log/boot.log.
It's often useful to log your own sysadmin activity in /var/log/messages. Since these are interleaved with messages from system processes, it's easy to determine the the sequence of events. You can create log entries from the command line or in a script by using the logger program; it is perhaps most convenient to define an alias to do this:
You can execute the note alias with a some text any time you want to create an entry in the log file.
It can be useful to collect messages from a group of machines (or virtual machines) into one log file. This centralizes your logs for easy examination, and it makes it harder for an intruder to hide their tracks by altering the log file (since they need to compromise the log server in addition to the primary attack target). To configure the log server to accept messages from remote machines, add -r to the SYSLOGD_OPTIONS line in /etc/sysconfig/syslog, open up UDP port 514 on the server's firewall, and restart syslog with the command service syslog restart
To configure a client system to send messages to a log server, add a line to /etc/syslog.conf with a destination of @logserver, where logserver is the hostname of the system accepting log messages (make sure the hostname is resolvable by placing it in /etc/hosts). Here is an example, which logs all messages of priority notice and higher to the host logmaster:
Many LAN devices such as routers and networked printers can also be configured to send messages to a log server.
An enhanced version of syslog named syslog-ng is available in the Fedora repositories. Fedora 8 will introduce rsyslog, which supports encrypted and authenticated log message forwarding, message rewriting, filtering based on message content, and the use of MySQL as a message store (enabling advanced reporting using SQL queries).
Wednesday, July 18. 2007
Cron is the Unix/Linux task scheduler. It uses crontab (cron table) files to specify the date and time that specific tasks are to be executed. The master system-wide crontab file is /etc/crontab; additional system-wide crontab files may be placed in /etc/cron.d, and personal crontab files (which are managed with the crontab command) are placed in /var/spool/cron/.
The master crontab file looks like this:
The name and value pairs at the start of this file set up exported environment variables. The remaining lines contain five date and time fields (minute, hour, day of the month, month of the year, and day of the week), the account name under which the command should be executed, and the name of the command. (Personal crontab files are installed with the crontab command and do not contain the account name field).
The run-parts script simply runs each of the scripts within the specified directory. One of the scripts in each of those directories is named 0anacron and is designed to update timestamp files stored in /var/spool/anacron; these timestamps are used by the anacron system at boot time to ensure that the daily, weekly, and hourly jobs still get executed even if the computer is never on between 4:00 and 5:00 am.
For example, an office system which is turned off by the user each evening and turned on at 9:00 am each morning will never be on at 4:22 am when the scripts in the /etc/cron.weekly directory are executed. One of the jobs performed weekly is makewhatis, which rebuilds the whatis database used by the apropos, man -k, and whatis commands, so those commands would never have access to an up-to-date index. To solve this problem, when the system is booted, the init script /etc/rc.d/init.d/anacron checks the file /var/spool/anacron/cron.weekly to see when the scripts in /etc/cron.weekly were last run; if it was more than 7 days ago, the scripts are executed after a brief delay using run-parts.Packages that requires scheduled execution of jobs can be configued in either of two ways: they can include a crontab file which will be placed in /etc/cron.d (the approach used by the smolt package), or they can include a script file which will be placed in /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly, or /etc/cron.monthly (which is the approach used by cups).
Wednesday, July 11. 2007
Fedora's application menus include many different programs from different packages. Fedora supports multiple desktop environments, including GNOME, KDE, and Xfce, and each of these has a different menu structure, which may include or exclude certain proograms, such as the control panels for each environment. Each menu title and menu entry can be be presented in multiple languages. Furthermore, the menu layout has changed between Fedora releases, even though some of the packages have not changed. How does this all work?
Wednesday, July 4. 2007
Most Fedora users realize that there are two ways to locally log in to a Fedora system: using a character-mode display, or through the graphical user interface. In the default configuration, six separate character-mode login screens are available, accessed by pressing Ctrl-Alt-F1 through Ctrl-Alt-F6. The X server which underlies the GUI display operates on another virtual terminal, accessed with Ctrl-Alt-F7. When you boot your system into runlevel 3, only the character-mode logins are available; when you boot into runlevel 5 (which is the default), the GUI is also started. To change the default runlevel, edit /etc/inittab and change the second field of the initdefault line; it makes sense to boot server systems into runlevel 3, because the GUI will be rarely used and unnecessarily consume memory which could be better used for other purposes (you can start the GUI at any time by switching to runlevel 5 (init 5) or by starting the GUI after login (startx)).
The login prompt presented on the character-mode screens is taken from the file /etc/issue. In some old versions of Fedora the /etc/issue file was overwritten at each boot by the startup scripts, but this is no longer the case. The default login prompt looks like this:
The italicized text will vary according to your kernel, CPU architecture, and hostname. This is configured in /etc/issue as:
Fedora release 7 (Moonshine)
Several substitutions are available within the text:
The line ending in "login:" comes from the mingetty program.
You can include as much or as little text as you want in this file, but it's foolish to include more than one screenful. Some examples:
If you provide telnet access to your system, which should only be done for low-security / no-security systems, a similar pre-login message can be provided for remote users in the file /etc/issue.net.
Wednesday, June 27. 2007
The /etc/aliases file contains e-mail aliases for your system. If you examine this file, you will find a large number of pre-defined entries:
RFC2142 defines many standard aliases which are expected to be present on an Internet mail server, including webmaster, hostmaster, postmaster, info, support, and abuse. Others are defined by convention, and some are defined to capture once-common security attacks (decode).
But without knowing how a particular system will be used, and what accounts will be created on that system, where should all of these aliases be directed? Fedora is configured to send all of this mail to the one account that is guaranteed to exist: root.
If your system is used as a publicly-accessible mail server, it's important to redirect these aliases to a mailbox that someone will actually monitor. The easiest way to do that is to uncomment the very last line of the file and change marc to the name of a valid user (preferrably the system administrator). For example, if you wanted to redirect all of these aliases to jessica, the last line of the /etc/aliases file should read:
You can also redirect individual addresses to specific people or lists of people, including non-local addresses:
After editing /etc/aliases, it's a good idea to run the newaliases command (though this should not be required with the current version of sendmail).
php_network_getaddresses: getaddrinfo failed: Name or service not knownphp_network_getaddresses: getaddrinfo failed: Name or service not known