Copied here for reference. Not my work, work of agriffis
daemonizing bash
April 20th, 2010 by agriffis
Before we jump into this, let's be clear about intent: There are better languages for writing daemons than bash. Honestly, any other language is probably a better choice. Writing a daemon implies that you're writing a sufficiently complex program that bash is already the wrong language, with or without daemonization!
But if you find yourself in the unfortunate position of needing to daemonize an existing bash program, and you'd rather put off rewriting it in a more suitable language, keep reading! I found myself in that position recently and kept some notes.
Daemonizing a process consists of two primary tasks: forking to the background to return control to the shell, and preventing undesirable interaction between the process and the host. Rich Stevens enumerated the steps in his classic Advanced Programming in the UNIX Environment. Here's my summary of his formula with implementation notes for bash.
Call fork (to guarantee the child is not a process group leader, necessary for setsid) and have the parent exit (to allow control to return to the shell).Forking in bash is a simple matter of putting a command in the background using "&". To put a sequence of commands in the background, use a subshell: "( commands ) &". Note that bash doesn't provide any method for the child process to continue the same execution path as the parent, so the entirety of the child must be contained in the subshell. The easiest way to do this is implement the child as a bash function: "childfunc &".
Call setsid to create a new session so the child has no controlling terminal. This simultaneously prevents the child from gaining access to the controlling terminal (using /dev/tty) and protects the child from signals originating from the controlling terminal (HUP and INT, for example).Bash provides no method to call the setsid syscall for the current process. We have two less-than-ideal alternatives:
The util-linux-ng package provides an external setsid command but this daemonizes an external command rather than the currently running script. It also makes collecting the PID of the child tricky because the setsid command will fork internally. Having said all that, if your application allows you to use the setsid command, it's a good choice because bash can't otherwise fully protect against the child process opening /dev/tty. It's still a good idea to redirect std* to prevent stray output to the terminal.
Lacking the setsid syscall, there are steps we can take to partially protect the child process from the effects of the controlling terminal:
Redirect std* to files or /dev/null
Guard against HUP and INT by signal handler in child
Guard against HUP by disown -h in parent
Unfortunately without setsid there is no way to guard completely against a subchild opening /dev/tty until the terminal emulator exits, then /dev/tty will become unavailable.
Change working directory to / to prevent the daemon from holding a mounted filesystem open.Bash is good at this.
Set umask to 0 to clear file mode creation mask.I have to admit that I can't understand the point of this, in bash or any other language. It seems to me that the child will either set its umask explicitly before creating files, or it will set individual file permissions explicitly, or it will fall back on the caller's umask. In the last case, I want my inherited umask, not the wide-open zero.If anybody wants to explain a good reason for step 4, I'm all ears... Until then, it's commented out in my implementation below.
Close unneeded file descriptors.This step is fun in bash using eval and brace expansion...
With those notes in-hand, here's my implementation. There are two
functions here, "daemonize" for an external command using setsid,
"daemonize-job" for a function in the running script.
Once it is installed, you will need to update flash. The easiest way to do that is to run huludesktop and let it do it. Prior to that, the key for the adobe flash player will need to be retrieved. The following will do that, and allow the install to run thru.
This is the version needed, Adobe Flash Player 10.0.32.
To create a backup of the main data on my raid system for removal offsite, I'm using 2 2tb drives. I attach them to a utility system and create a Logical Volume group which fills both. the current set I'm using was created by installing a system and allowing it to create the LVM spanning both drives. As such one of the drives has a few gb of space at the front with a root boot partition, which is a primary partition not in the LVM. On the original system once booted, the LVM had the root, home and another boot partiton inside the LVM.
In order to mount this one needs to install some tools on the system. I found a page advising to install two gui's which are quite useful.
One is a KDE utility KVPM. It or the other utility drags in the lvm tools. Another one is system-config-lvm.
The command line tools allow installation of the lvm. The lvm scans all disks for logical volume groups. These are marked with unique ID's from when they are created. All are shown via the commands in the lvm command.
vgdisplay shows information on the volume group: --- Volume group --- VG Name vg_apex2 System ID Format lvm2 Metadata Areas 2 Metadata Sequence No 4 VG Access read/write VG Status resizable MAX LV 0 Cur LV 3 Open LV 1 Max PV 0 Cur PV 2 Act PV 2 VG Size 3.64 TiB PE Size 32.00 MiB Total PE 119216 Alloc PE / Size 119216 / 3.64 TiB Free PE / Size 0 / 0 VG UUID ISZMQ4-BNdD-J9Cf-f72S-GgiI-TslM-w8sSqm
lvm> pvdisplay --- Physical volume --- PV Name /dev/sdb2 VG Name vg_apex2 PV Size 1.82 TiB / not usable 28.00 MiB Allocatable yes (but full) PE Size 32.00 MiB Total PE 59600 Free PE 0 Allocated PE 59600 PV UUID cdqH1r-Z873-mmC4-XZpY-Vsrc-YXd1-PwF8VS
--- Physical volume --- PV Name /dev/sdc1 VG Name vg_apex2 PV Size 1.82 TiB / not usable 16.00 MiB Allocatable yes (but full) PE Size 32.00 MiB Total PE 59616 Free PE 0 Allocated PE 59616 PV UUID hJyfL3-RbkR-SxbM-ffHk-q70G-1iu9-6r58yx
The next thing that has to be performed is to make the volume group visible to the system. The vgchange -ay makes the volume group active. Once it is active /dev/vg* will be visible and the members of each vg directory are the file systems. After the vgchange is performed, all the need be done is to mount the volume group, such as;
I have been trying to run a java app which will open a port on a machine other than the one which it is downloaded from. someone suggested a signed app would work, where an unsigned one does not.
Here is how to sign the app. first you have to have the java sdk on your system.
use keytool to create an alias with a password. Answer questions asked to create a key. A file .keystore will be created with the certificate you create.
keytool -genkeypair -alias jws
Use jarsigner to sign the jar. Use the alias you created above to sign the jar.
jarsigner VncViewer.jar jws (for example).
You will be for the password used in the keytools command.
Your jar will now cause a prompt when you load it on the browser with a query about if you trust the author.
This didn't fix the problem with the network, but it was useful enough to note.
Oracle trashed all the links into the Sun java pages when they moved them to their domain, so this information is probably linked to a million times, but the links now go to the generic oracle forum pages. Still hunting for how to authorize a connection to another IP.
I decided to figure out how to replicate a local install repository for Ubuntu. Since 10.4.1 is working well, I started with it but probably will do 10.10 as well when I figure this out.
Here is a link to how to create a repository locally. It has a good walk through and allows making a setup for hosting individual packages. The other bit is to download all the packages, about 30gb for the entire repository. That is running since this morning at 730 (about 17 hours so far) and reads that the process is 58% complete as of midnight the same day. Total downloaded so far is 18gb.
This document contains an overview of the principal RPM commands
for installing, uninstalling, upgrading, querying, listing, and
checking RPM packages on your Red Hat Linux system.
Used to install a RPM package. Note that RPM
packages have file naming conventions like foo-2.0-4.i386.rpm,
which include the package name (foo), version (2.0), release (4), and
architecture (i386). Also notice that RPM understands FTP and HTTP
protocols for installing and querying remote RPM files.
# rpm -e foo
To uninstall a RPM package. Note that we used the
package name foo, not the name of the original package file foo-2.0-4.i386.rpm
To upgrade a RPM package. Using this command, RPM
automatically uninstall the old version of the foo package
and install the new package. It is safe to always use rpm -Uvh
to install and upgrade packages, since it works fine even when there
are no previous versions of the package installed! Also notice that RPM
understands FTP and HTTP protocols for upgrading from remote RPM files.
# rpm -qa
To query all installed packages. This command will
print the names of all installed packages installed on your Linux
system.
# rpm -q foo
To query a RPM package. This command will print
the package name, version, and release number of the package foo
only if it is installed. Use this command to verify that a package is
or is not installed on your Linux system.
# rpm -qi foo
To display package information. This command
display package information including the package name, version, and
description of the installed program. Use this command to get detailed
information about the installed package.
# rpm -ql foo
To list files in installed package. This command
will list all of files in an installed RPM package. It works only when
the package is already installed on your Linux system.
# rpm -qf /usr/bin/mysql
mysql-3.23.52-3
Which package owns a file? This command checks to
determine which installed package a particular file belongs to.
List files in RPM file. This command allows you to
query a (possibly) uninstalled RPM file with the use of the the "-p"
option. You can use the "-p" option to operate on an RPM file without
actually installing anything. This command lists all files in an RPM
file you have in the current directory. Also note that RPM can query
remote files through the FTP and HTTP protocols.
# rpm --verify mysql
To verify an installed package. This command will
list all files that do NOT pass the verify tests (done on size, MD5
signature, etc). Where a file does NOT pass, the output is listed using
the following codes that signify what failed:
S File size
M Mode (includes permissions and file type)
5 MD5 sum
L Symlink
D Device
U User
G Group
T Mtime
Take for example the following:
# rpm --verify mysql
S.5....T c /etc/my.cnf
This example indicates that file /etc/my.cnf failed on:
File size
MD5 Sum
Modified Time
However, the "c" tells us this is a configuration file so that explains
the changes. It should still be looked at to determine what the changes
were.
# rpm --checksig foo
To check a RPM signature package. This command
checks the PGP signature of specified package to ensure its integrity
and origin. Always use this command first before installing a new RPM
package on your system. Also, GnuPG or Pgp software must be already
installed on your system before you can use this command.
urpmi
urpmi for mandrake configuration. following adds mounted cd's to
search list. note that the path you select
is the one with all the .rpm's. this isn't really specified
anywhere that well. No clue whether hdlist is good to go,
or synthesis.hdlist is. I selected synthesis and it seemed to
install mozilla.
the "relative" path that is asked for is the one to get to the hdlist
from wherever the rpms are.
The /etc/urpmi/urpmi.cfg file will contain a key number. If
messing with this, it is not clear where this comes
from. It may be from the md5 checksums on the rpms, or somewhere
else. If manually messing with the
config what is not known is where that comes from
urpmi.addmedia cd1 file://exportiso/mandrake-cd1/media/main with
../media_info/synthesis.hdlist1.cz
urpmi.addmedia cd2 file://exportiso/mandrake-cd2/media/main2 with
media_info/synthesis.hdlist.cz
urpmi.addmedia cd3 file://exportiso/mandrake-cd3/media/main3 with
media_info/synthesis.hdlist.cz
following are paths of mounted cd images on the system.
directory contains images:
//eng-w2k/LinuxDownloads on /export/eng-w2k-linuxdownloads type smbfs
(0)
images are loop mounted this way:
/export/eng-w2k-linuxdownloads/Mandrake/Mandrakelinux-10.1-Community-Download-CD1.i586.iso
on /exportiso/mandrake-cd1 type iso9660 (rw,loop=/dev/loop0)
/export/eng-w2k-linuxdownloads/Mandrake/Mandrakelinux-10.1-Community-Download-CD2.i586.iso
on /exportiso/mandrake-cd2 type iso9660 (rw,loop=/dev/loop1)
/export/eng-w2k-linuxdownloads/Mandrake/Mandrakelinux-10.1-Community-Download-CD3.i586.iso
on /exportiso/mandrake-cd3 type iso9660 (rw,loop=/dev/loop2)
Where X=max number of processes. WARNING: This
won't work for "make dep".
Since running multiple compilers allows a machine
with sufficient memory to use use the otherwise wasted CPU time during
I/O caused delays make MAKE="make -j 2" -j 2 actually even helps on
uniprocessor boxes (from Ralf B.chle).
Solaris DHCP fix
Someone else posted this solution for unknown hostname with dhcp soloaris.
First
of all, For Solaris 8 we need to edit the file /etc/init.d/network and
change the line that reads. You can put a #sign before the line to
disable it or change the line completely.
"dhcp") hostname=`/sbin/dhcpinfo Hostname` ;;
to
# "dhcp") hostname=`/sbin/dhcpinfo Hostname` ;;
"dhcp") hostname=`shcat /etc/nodename` ;;
Then, edit the file /etc/init.d/inetsvc and change the line that reads
hostname=`/sbin/dhcpinfo Hostname`
to
# hostname=`/sbin/dhcpinfo Hostname`
hostname=`/usr/bin/cat /etc/nodename`
Save the files and reboot the system. The system's hostname will be
the entry in the file /etc/nodename.
Sorry for the delay writing this Summary:
This *is* in the list archives but I found I had to really dig and piece it
together. maybe its just me. :-)
Here is what worked for me in hopes that it benifits others - your mileage
may vary.
Create or edit the files outlined and reboot:
/etc/nodename
yourhostname
/etc/hostname.elxl0
inet yourhostname
edit /etc/default/dhcpagent and set
REQUEST_HOSTNAME=yes
Create this script:
-cut-
/etc/init.d/set_hostname
#!/sbin/sh
HOSTNAME=`cat /etc/nodename`
echo "Setting hostname to $HOSTNAME... \c"
uname -S $HOSTNAME
echo "Done."
-cut-
Symlink /etc/init.d/set_hostname to /etc/rc2.d/S70set_hostname
Thanks to Hichael Morton, Alan Pae, Paul Boven, Sid Wilroy, Gerard Henry,
Dave Miner and Mitchell Bruntel and others who replied and provided
suggestions to me.
[root@purple]# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/cantin/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/cantin/.ssh/id_rsa.
Your public key has been saved in /home/cantin/.ssh/id_rsa.pub.
The key fingerprint is:
ba:d0:f0:0d:de:ad:be:ef:ff:aa:dd:ee:99:88:77:dd root@purple
creates .ssh/id_rsa.pub
for convenience, rename this <hostname>_id_rsa.pub in this
case purple_id_rsa.pub
copy this to system to log into. add to authorized_keys2 with
text edit append.
[root@purple]# cat authorized_keys2
ssh-rsa <long string of crap>= root@somehost.com
ssh-rsa <long string of crap>= root@localhost
ssh-rsa <long string of crap>= root@jws80
this has to be performed for any login id on any system
For Keepalive, use
Host *
Protocol 2
ServerAliveInterval 60
in the file
~/.ssh/config
Xwindows
X11 Session Forwarding
One lesser known feature of X windows is its network transparency.
It was
designed to be able to transmit window and bitmap information over a
network
connection. So essentially you can login to a remote desktop machine
and run
some X windows program like Gnumeric, Gimp or even Firefox and the
program will
run on the remote computer, but will display its graphical output on
your local
computer.
To try this out, you will need an account on a remote computer that
has X
windows installed with some X windows applications. suso.org servers do
not
have any such programs so you will need to either login to one of your
other
workstations or another server that does have them. The key to making
it work
is using the -X option, which means "forward the X connection through
the SSH
connection". This is a form of tunneling.
ssh -X username@desktopmachine.domain.com
If this doesn't work, you may have to setup the SSH daemon on the
remote computer
to allow X11Forwarding, check that the following lines are set in
/etc/ssh/sshd_config on
that computer:
For some newer programs and newer versions of X windows, you may
need to use
the -Y option instead for trusted X11 forwarding. Try using this option
if your
X11 windows program fails to start running with a message like this one
that was
for Gimp:
The program 'gimp-2.2' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
(Details: serial 154 error_code 3 request_code 38 minor_code 0)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error()
function.)
reset server keys
How to regenerate new ssh
server keys
This is an unusual topic since most distribution create these keys for
you during the installation of the OpenSSH server package. But it may
be useful to be able generate new server keys from time to time, this
happen to me when I duplicate Virtual Private Server which contains an
installed ssh package.
SSH1 protocol
For SSH1 protocol, you need a rsa1 key generated has follow:
The Firefox Web browser is quickly
becoming one of the most
prominent Web browsers available. The fact that it is cross-platform
makes it a
comfortable browser for users who have to use more than one OS. There
are,
however, a number of hidden "gems" that you can enable that make
Firefox even more powerful than it is "out of the box."
To increase the speed of opening Web
pages, there are two
options you can tweak. The first is to enable HTTP pipelining, which
allows
Firefox to request multiple files simultaneously rather than one at a
time. To
enable this, type about:config in the
address bar. Scroll down the list until you find network.http.pipelining
and set it to true. You can also enable network.http.proxy.pipelining
as well.
To speed up rendering speeds, you can tell
Firefox not to wait
the default quarter second before drawing Web content. The option to
look for
here is the nglayout.initialpaint.delay,
but it may not be displayed in the preference list by default. If not,
right-click
on the screen and select New | Integer. Type nglayout.initialpaint.delay
as the preference name and the number 0
as the value. By default, Firefox uses a value of 250 (milliseconds).
Finally, the last gem is not a preference
modification but an
invaluable extension that is extremely useful for anyone doing Web
development.
In Firefox, click Tools | Extensions and a new box will open. Click on
Get More
Extensions. In the new page that opens, click on Developer Tools under
the All
Extensions sidebar. Jump to the last page and install the Web Developer
extension. Once the extension is installed, restart Firefox and you'll
see a
new toolbar with a number of options that include the ability to
quickly
validate HTML and CSS, view image dimensions, outline tables and table
cells,
and a lot more.
Setting up XDM requires you to change the run level of your system.
The run level controls which mode the
system is running in when it is rebooted. It can run in single user
mode, multiuser mode without networking,
multiuser mode with networking and multiuser mode with XDM running. My
system is Red Hat 5.1 and it uses run
level 3 for normal multiuser operation and run level 5 for XDM
operation (multiuser, plus starting X at boot
time). Edit your /etc/inittab file as the root user to change the run
level of the system. First, make sure
the XDM run level exists in /etc/inittab. It should look something like
this and is usually located near the
end of the file:
# Run XDM in run level 5
x:5:respawn:/usr/bin/X11/xdm -nodaemon
This is the entry from Red Hat 5.1. Slackware, Debian, SuSE and
other Linux Distributions with X should be
similar. The run level number is 5 in this case, but may be different
in your distribution.
You can test the XDM run level by typing init 5. If the
login box appears and everything looks
okay, you can change the default initlevel for bootup or experiment
with the XDM changes without rebooting
your system. If you don't want XDM to start at boot time, skip ahead to
the next section.
Make a backup copy of the /etc/inittab file before you change
anything. Rename it to something like
inittab.bak.1, then look for the initdefault line, which is usually
near the start of the /etc/inittab file.
Since you are not yet running XDM, yours probably looks something like
this:
id:3:initdefault:
To make your system start XDM at boot time, you change the 3 in this
line to equal the number in the XDM
run level line. In my case, I changed the 3 to a 5. Reboot your system,
and a gray screen with a box in the
middle asking for a user name and password will
appear. You can log in and make sure everything is running
okay, but that isn't necessary to complete this tutorial.
Customizing XDM
Now that XDM is up and running, we can start making changes. We will
be switching between a text-mode
login and the XDM screen. To get to the text mode console, press <H>ctrl<H>-<H>alt<H>-F1; to get back to
the XDM screen, press <H>ctrl<H>-<H>alt<H>-F7. With some
distributions, you may have to use
<H>ctrl<H>-<H>alt<H>-F6 for the XDM
screen.
Change to text mode and log in as root. Change directories to
/usr/lib/X11/xdm and look at the files
present in this directory. These files control the behavior of your
system when XDM is started and a user
logs in using XDM. The files we are concerned with are:
Xsetup (or Xsetup_0), which sets up the XDM screen
Xresources, which controls the behavior of the xlogin widget
Changing the Background Color
Let's start by changing the background color to something other than
gray. You can use any program which
can display an image or color on the background, which is sometimes
called the root window. One program
included with the X distribution is xsetroot.
Edit the Xsetup file and
comment out any programs that may already be setting the background
image, like xbanner, xv or xsetroot. Add
the following line:
/usr/X11R6/bin/xsetroot -solid steelblue
Color names like steelblue are defined in the /usr/lib/X11/rgb.txt
file. This maps color names to the
actual Red/Green/Blue color settings, making things more readable. If
you use a color name that has spaces in
it, you need to enclose them in quotes, e.g., ``navy blue''.
Save the Xsetup file and switch back to the XDM display by using <H>ctrl<H>-<H>alt<H>-F7 (or F6,
depending on which virtual console the
X server is using for its display). Then restart XDM by pressing
<H>ctrl<H>-<H>alt<H>-<H>backspace<H>.
Note: do not use the <H>del<H> key. It will reboot the whole system
instead of just restarting XDM.
You should now have a nice, solid steel-blue background. You can
experiment with different colors until
you find one that you like.
Changing the Background Pattern
A bitmap can be used to tile (copied over and over to cover the
whole display) a simple two-color image
onto the background instead of a solid color. There should be a
collection of bitmaps in
/usr/include/X11/bitmaps. You can also create your own using the bitmap
program included with X windows. Try
changing the xsetroot line to this:
Restart XDM as before, and you should now have a nice winter scene.
You can change the foreground and
background color with the bitmap by adding the -fg and -bg
options and specifying a color. Try
changing it to this:
/usr/X11R6/bin/xsetroot -bitmap\
/usr/include/X11/bitmaps/xsnow -fg blue -bg yellow
Not the most wonderful colors for snow, but you get the idea. The
colors recognized by the -fg and -bg options are the same as the ones in the rgb.txt file
discussed above.
You can also tile color bitmaps stored in the xpm format. The xpmroot
program is used for this. Change the xsetroot line to something like
this:
Now that we can display colors and tiled bitmaps on the background,
it is time to display a picture on the
background. To do this, I use a shareware graphics program called xv. You
can get it from the xv home page at http://www.trilon.com/xv/, or it may be included
with your Linux distribution. Remember, this is
shareware, and you should support the author by sending him $25 if you
find his program useful.
I have chosen to use xv, but any program capable of displaying an
image on the background can be used. For
xv, you tell it to display the image centered on the background. You
also want it to exit immediately after
displaying the image; otherwise, XDM will hang until the xv program is
exited manually.
I use this to put a picture in the center of the display. To view
your changes, save the Xsetup file and
press <H>ctrl<H>_<H>alt<H>-F7 to switch
back to the XDM screen. Press <H>ctrl<H>-<H>alt<H>-<H>backspace<H>
to restart the X server. You
should now see your image in the center of the screen, covered by the
login box. xv supports several other
placement options using the -rmode command. You can see
a list of these options by typing xv -rmode -1.
With the help of a simple Perl script, you can display a random
image on the background each time XDM is
run. Listing 1 is a simplified version of a script written by Scott
Scriven, toykeeper@cheerful.com.
You may also have to change the path to xv and find
to match your local
setup. Including the absolute paths in the script ensures it will work
correctly, even when the $PATH
environment variable isn't set.
To load a random background, change the xv line in Xsetup to
usr/local/bin/bkgd instead. Create a
/usr/lib/X11/backgrounds directory and fill it with your favorite
images. A couple of good places to look for
background images are http://www.digitalblasphemy.com/ and http://ipix.yahoo.com/.
Listing 2 is a working Xsetup file with the intermediate steps
commented out with ``#'' characters.
listing 1:
#!/usr/bin/perl -w
# This picks a random background from
# /usr/local/lib/X11/backgrounds,
# and calls an image viewer to set it as the
# background.
# This script is released under the GPL version 2.
# Putting the picture into a sub-directory named
# max will make sure it is
# resized to take up the whole background.
# Feel free to change the directory the images are
# stored in...
$bkgddir = "/usr/lib/X11/backgrounds";
# And if you'd like to use a different viewer, set
# it here.
$xv = "/usr/bin/X11/xv -root -quit +noresetroot\
-rmode 5";
$max = " -maxpect";
srand;
$tmp = '/usr/bin/find $bkgddir/* ! -type d\
-print';
@pictures = split(/\n/,$tmp);
$picture = splice(@pictures, rand @pictures, 1);
if($picture =~ /max/) { $xv .= $max; }
Listing 2. Xsetup
#!/bin/sh
# $XConsortium: Xsetup_0,v 1.3 93/09/28 14:30:31
# gildea Exp $
# Display gromit's picture on a black background
# /usr/bin/X11/xv -root -rmode 5 -quit
# /root/.gromit01.jpg
# Display a random image
/usr/local/bin/bkgd 1> /tmp/bkgd.1.log 2> /tmp/bkgd.2.log &
# Set the background to a color
#/usr/X11R6/bin/xsetroot -solid steelblue
# Tile the snowflake bitmap on the background
#/usr/X11R6/bin/xsetroot -bitmap /usr/include/X11/bitmaps/xsnow -fg blue
-bg\
yellow
# Tile an .xpm file on the background
#/usr/X11R6/bin/xpmroot
#/usr/include/X11/pixmaps/xpovicon.xpm
# Display a clock with black background and white
# hands
/usr/bin/X11/xclock -hl white -hd white -bg black\
-fg white -geometry 100x100+0+0 &
Customizing the Login Box
Now we want to customize the xlogin box using the
/usr/lib/X11/xdm/Xresources file. This file is also used
for configuring other XDM widgets like the chooser, but we aren't going
to deal with these other options
here--see the XDM man page to learn about them.
We can move the xlogin box, resize it, change its color, its fonts
and what it says. I have moved mine
into the lower-right corner and made it as small as I can, so that it
doesn't cover up the background
image.
The XDM xlogin widget uses X resources to specify these settings.
They are all stored in the Xresources
file and are read by XDM each time it restarts. A list of the available
options, taken from the XDM man page,
is shown in ``Xresources Options''. I will go through each option and
explain its use.
I have ignored several more advanced xlogin resources, some of which
may appear in the Xresources file. It
is safe to leave them alone--the defaults set when you installed X
should work fine. The XDM man page
contains full descriptions of each option, if you want to experiment
with them.
Move and Resize the xlogin Box
The .width, .height, .x and .y
settings can be used to set the size and screen
position of the xlogin box, or you can use .geometry to specify
all of these at once. Let's move the
login box to the lower-right corner and make it 300 by 250 pixels. The
screen coordinates to be used start
with 0,0 in the upper-left corner, and the coordinates of the
lower-right corner will depend on your screen
resolution. But X has another way to specify coordinates: -0,-0
is the lower-right corner of the
display, no matter what the screen size. Add this line to the
Xresources file, near the other xlogin*
definitions:
xlogin*geometry: 300x250-0-0
Save the file and restart the x server as you did after changing the
background image. Your login box
should now fit snugly into the lower-right corner of the display,
revealing more of your background
image.
Now we can change the colors. There are five resources relating to
color in the above table. First, change
the default foreground and background colors for the box using the xlogin*foreground
and .background settings. Let's make it black on blue:
xlogin*foreground: black
xlogin*background: steelblue
Save and restart the X server to make sure your changes have taken
effect. The greeting and login prompt
did not change color, because you haven't changed them yet. You must
specify each individual color you want
to change. The .greetColor setting is the greeting that is
displayed at the top of the box. .promptColor is the login: and password: prompt color, as well
as the text you enter for your user
name. .failColor is used for when the user name or password
entered is invalid.
Try out these settings:
xlogin*foreground: black
xlogin*background: steelblue
xlogin*greetColor: white
xlogin*promptColor: grey
xlogin*failColor: red
Not a terribly inspiring color scheme, but better than black on
white. Play around with it until you find
the colors you like.
Changing the xlogin Fonts
The resources that control the four fonts we want to change are:
xlogin*font: used for displaying the typed-in user name
xlogin*greetFont: used to display the greeting
xlogin*promptFont: used to display the prompts username:
and password:
xlogin*failFont: used for displaying that the login failed
Fonts under X are difficult to deal with. They have an abundance of
options and modifiers, most of which
are never used. The xfontsel program
can make font selection much easier.
Just browse through the fonts, selecting the font style, size and
attributes you want. Then click on the
select button and paste the font string into the Xresources file using
your middle mouse button, or both
mouse buttons at once if you have a two-button mouse. Add these lines
to your Xresources file:
Experiment with the different fonts and sizes until you find something
you like.
Changing the xlogin Prompts
You can also specify the text that is displayed for each of the four
prompts associated with the xlogin
widget. .greeting can be set to CLIENTHOST and will
display the full host name of the system it
is running on. The .namePrompt value is displayed to ask for
the user name, .passwdPrompt asks
for the password, and .fail is displayed when an unsuccessful
login occurs. For example:
X distributions usually include the xclock program which can display
a nifty looking analog clock. Add it
to your XDM screen by inserting this line in your Xsetup file:
xclock -hl white
-hd white -bg black -fg white\ -geometry 100x100+0+0 &
This will display an analog clock of moderate size in the upper-left
corner of the screen. The clock may
stay running, even after a user has logged in.
Well, that's about it for the basic customization of XDM. There are
many things to play with, and
hopefully I have given you a good framework with which to begin
experimenting. No two users have the same
tastes, so it may take some time before you finally get the look and
feel you want.
Login manager:
/etc/sysconfig/displaymanager and change
DISPLAYMANAGER=”xdm” to
DISPLAYMANAGER=”kdm”
********************
VNC Server/Client Quickstart
VNC Server Quickstart Instructions
I performed this on Red Hat Advanced Server 2.1 and Fedora Core 1 and
2. It should work on Red Hat 7.3, 8,9 and Enterprise 3.
Note: I would only recommend using VNC between hosts behind a
firewalled environment. Passwords are transmitted in clear text.
If
you simply must use VNC to use a GUI remotely outside of a firewall I
would recommend connecting via SSHv2 to the VNC Server, then initiating
VNC inside the SSH Tunnel.
On VNC Server machine with vnc-server installed
1)Type vncserver -geometry 800x600 (or whatever resolution you prefer)
2) There will be a session number displayed .This will create a .vnc
directory in your home directory. (/home/yourself/.vnc)
3) Type cd /home/yourself/.vnc
4)Type ls -alc
-You should see a script called xstartup
5)Type vi xstartup or use whatever text editor you prefer
-This is where we will setup your vnc session to use your window
manager of choice
-Find
the section where it says twm & and replace it with your choice. I
know there are more, but these seem to be the most popular ones. Don't
include what I have in the parenthesis
-startkde & (used for the KDE window manager)
-exec gnome-session & (used for the Gnome window manager)
-startxfce4 & (used for the XFCE4 window manager, my favorite
choice)
6)Now type vncserver -kill:1 (1 is our session number)
-This stops the VNC Server so that the xstartup script we just edited
can be re-read when we restart the server
7)Type vncserver (to start the session back up)
8)Type ps ax | grep vnc (check if your session is up and running)
Let's connect to the VNC Server!
From a Linux Box with the vncviewer package installed
1)Type vncviewer hostname or IP address:1 (1 meaning whatever session
number you chose)
2)Enter your Linux local account password assigned on VNC Server machine
From a Windows Box with TightVnc or RealVnc client installed
1)Start your VNC client and type the VNC Server hostname or IP
address:1 (1 meaning whatever session number you chose)
or
From a Java Enabled Browser on any platform (not the best but it works)
1)Type http://IP address of VNC Server:580x (x will indicate session
number)
ex..http://192.168.1.6:5801 ( for session 1)
ex..http://192.168.1.6:5802 ( for session 2)
Note:
1)I keep getting new session numbers every time I type vncserver. I
just want session 1 running
-By
default each session is still active even after disconnecting from
remote vnc session. -You only type vncserver if you want to use
multiple sessions
-You can kill the extra sessions by typing
vncserver -kill:session number or ps ax | grep vnc to see which
sessions are running, then type kill -9 ID number of the session you
don't want
-If it all gets messed up you can start over with the
sessions by typing rm -rf .vnc in your home directory on the VNC Server
machine. Then go into your /tmp/.X11-unix directory and remove
X1,X2...etc for each session number (Don't try and remove the X0 file!)
What it is saying now is nothing more than "If you connect to ftp.freebsd.org, login as anonymous and use test@someplace.com
as password." and "If you connect to
myownmachine, login as myusername and use mypassword
as password.".
Macro definitions
This part of the .netrc consists of macros which can be used to
perform automated tasks:
macdef uploadtest
cd /pub/tests
bin
put filename.tar.gz
quit
macdef dailyupload
cd /pub/tests
bin
put daily-$1.tar.gz
quit
Keep in mind that there should be an empty line after the last
macdef statement. If you don't do this, ftp will complain about it.
The first one is saying "Go to the /pub/tests directory, switch to
binary mode, put a file there and quit it". The second one is saying
the same, except that the name of the file is based on a parameter
on the macro-call (see Usage of the .netrc for more about
this).
Usage of the .netrc
Macros can be called from both inside ftp:
[~] chichi>ftp myownmachine
ftp: connect to address ::1: Connection refused
Trying 127.0.0.1...
Connected to localhost.
220 myownmachine FTP server (Version 6.00LS) ready.
331 Password required for myusername.
230 User myusername logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> $ uploadtest
cd temp
250 CWD command successful.
put filename.tar.gz
local: filename.tar.gz remote: filename.tar.gz
150 Opening BINARY mode data connection for 'filename.tar.gz'
100% |**************************************************| 1103 00:00 ETA
226 Transfer complete.
1103 bytes sent in 0.01 seconds (215.00 KB/s)
quit
221 Goodbye.
Linux supports the standard signals listed below. Several signal
numbers are architecture
dependent, as indicated in the "Value" column. (Where three values are
given, the first one is usually valid for alpha and sparc, the middle
one for i386, ppc
and sh, and the last one for mips. A - denotes that a signal is absent
on the corresponding architecture.)
First the signals described in the original POSIX.1-1990 standard.
