Well this page isn't quite as bad of a mess as it was when I first posted it.
Read it, and see. However section 5. isn't even started even though
there's lots of links to click on, they just don't go anywhere.
First a word about the CLI:
You, assuming you came from a Windows, or Mac environment, may have
the mistaken notion that the CLI,(Command Line Interface) is
difficult to learn, or hard to use. Nothing could be further
from the truth. Linux, if used properly is still primarily a
command line driven system, but unlike the command line of old, where
every single 'i' had to be dotted, and 't' crossed,
the command line of a modern 2007 bash shell completes commands for
you given a partially keyed in command by simply pressing the tab key,
the system either looks for executable commands matching the syntax of
the command you partially typed in and it completes the executable programs
name, based on an evolving executable hash table the
Executable PATH variable $PATH or a
file used with it, in the PWD,(Present Working Directory)
or if you press <Alt-Tab> it will draw from command history
for a match to the last partially entered command fragment you've keyed in
on the command line. If it can by inference divine the meaning you
intended, you're done, if not it interacts with you to obtain enough
information to infer what it is that you are attempting to do. Faced
with the lack of a unique solution, you press <ctrl-R> and
this mechanism prompts you for some unique fragment it can use to search
the previously entered command history to display previous complete
commands. Subsequent <ctrl-R> keys simply use the
same command search fragment to walk further back in history, presumably
you stop on the proper command when you see it, and if necessary make a
minor modification here or there, to hone the old command to your present
needs, and then press enter to execute the new command. If it executes,
or at least makes a solid attempt, this too becomes part of the history of
command execution.
The CLI in combination with GPM,(General Purpose Mouse) also
does things to make entering things at the command line easier, MUCH Easier!
Unlike the GUI,(Graphical User Interface) where you have to do 20 eye hand
cordinated mouse clicks, just to pull up a document that you were editing
yesterday, often four or five key taps is all that is needed. So why do
I bring up this example? I say so why not? What if Micro$oft never
existed. Never invented Winders. What if we had a GUI, that
played second fiddle to a command line, and that command line was as good
as Bash is today, back in 1988 or so. It could have happened that
way, it almost did. I saw a curious attempt, marketed by Epson,
that offered a command.com shell replacement that parsed your command
line entry, and if that operation resulted in an error it drilled down into
an Artificial Inteligence Data Base to give you some
examples of how to use the program it thought you were trying to key in.
While not quite what the bash shell is today, but at least it was going the
right direction. Why do I say Right Direction? Just
about this same time period Micro$oft introduced Windows 1.0 which
was a joke, if memory serves, it came on one or two 360K floppies, took
ten minutes to load, and didn't have any application programs to speak
of. Nothing to recomend it, except it was Micro$oft's way of showing
the public this is our view of the future. In truth they visited
PARC,(Palo Alto Research Community) took notes, and said yea,
we can do that. Next they advertised the hell out of it, and soon
there was a version 2.0, then 3.0 and by 3.0 people were actually trying to
use Windows. What if Epson had put that kind of effort into their
AI,(Artificial Intelligence) driven CLI? Well for one thing people
would know what a program was, what a file is, what a
subdirectory is. Let's cut to the chase, what if by 1988
we had the bash shell, with the GPM mouse, and an SVGA-Lib to standardize
graphics, or an X-server GUI, generally available to the public. Folks
would still script startup Icons, sure, you'd still click start your apps,
as you do today in Windows, but the difference is, you would be the one to
write the script to start them, because in doing so, you get to customize
how the app starts up, which custom features it starts up with, and when
Errors, and Warnings come up, they are printed out on the terminal that
started them running. When these things happen in Windows, the
user never knows about them. The Error/Warning messages are the
application program crying out in pain "Ouch" to the user, they are saying
"Don't do that, it hurts!" If today you keep doing
something that makes an application cry out Ouch you're hurting me, and you
don't know why, or what to do about it, so you ignore it, when the program
finally crashes, taking your precious data with it, at least you remember
those crys of pain, and maybe a little about what it was trying to tell you.
So that when you get with your buddies, and mention Memory-leak detected,
they know right where to go, to begin skulling the problem out. The
problem with Windows is that the end user is so effectively abstracted from
what is really going on, under the GUI Icon driven hood of this lean mean
muscle car of an operating system, that by the time they realize that
anything is amiss, there's a trail of broken rods, springs, a sporadic piston
here or there, bolts, nuts, an occasional fan blade to two, lining the
roadside for ten miles or more. Knowing the needs of your apps gives an
alert user the chance to at least backup your data before the crash, and a
power user, can partially bring a crashed app back to life, often just long
enough to save the file,(See Core Files). Many people tout
advantages of one operating system over another, and I am sure folks reading
this preamble will detect a vauge bias in my writing, especially this
part. In the Browser-box provided below I present one view
of the DMCA story, if you're already familiar with these industry
excesses skip over the Browser-box, and go on, but it makes an interesting
read so grab the Browser-box's left glider bar and give it a twirl, it's a
hoot... No Really, read it, you'll prabably like it.
I don't want to dampen your enthusiasm for an alternative operating system,
but I won't sugar coat it either. First off, don't think you are going
to make the switch from Windows to Linux overnight, large corporations do
that, but they have an army of tech support operatives on the payroll just to
deal with end user problems. Your best bet is to keep using your
Winbox, as you setup the Linbox, and learn the basics. Get Linux
networking up and running, set up Samba so that Linux and Windows can share
each others files. Next download, and install TerraTerm to the Winbox,
get the Secure Shell plugin for it, so that the Winbox can login to the
Linbox. This will allow you to control your Linbox from a Windows
desktop. These things require someone who is knowledgeable in both
Linux and Windows networking, hint having a geek for a friend is very useful
in this getting started phase. It will take about two years of serious
effort, to learn not only how to run and maintain a new operating system, and
all of the types of software you use, on a regular basis, how to migrate your
old data, into the new, and how to do workarounds for differences therein,
and to buy Linux compatible hardware, (Hint WinPrinters, and WinModems
often won't work under Linux) but also to adjust to the, new for you,
do it yourself paradigm. You see Open Source, is in reality a
far flung, closely knit community of users, that know how to get "some" things
done, they know how to, and who to ask, to get the
rest of it. Needless to say I have quite a lot to say on this subject,
nor is Linux your only choice, there's Hurd, FreeBSD, and soon Haiku OS
will resurrect BeOS as Open Source, and Open Solaris,
plus Linux itself comes in many flavors, RedHat, Debian, Gentoo, Mandrake,
Ubunto, DSL, and Slackware, to name just a few of the more prominent distros
and then there's Micro$oft's SuSE Linux under the auspices of Novell which
many say is a violation of the GPL,(General Public License), then
there's CodeWeavers, and Wine, which emulate Micro$oft Windows under Linux,
allowing you to run Windows programs from the safety of a Linux/BSD/Hurd
X-server, and trust me, I haven't even scratched the surface yet, for instance
Apple MacOsX, is an overlay for BSD running under every MacOsX machine
you see. BSD is Open Source, MacOsX is Closed Source how's that for
twisted.
An expanse of terminals as far as the eye can see:
And stacked as high as the sun!
Like everything else in Linux, default terminal settings are more like
minimal examples to whet your appetite, not anything you'd want to work
with on a day to day basis. None of any of these are really any fault
of Linux, or its design, rather they are configuration choices, that were
"made for your own good" by the distro
house. Many a Linux Distro fancy their self appointed mandate to
uplift new users, or to ease the transition from Windows to Linux.
Sooner or later this manifests as policy, and tends to become inflexible as
time marches on. While there's nothing wrong with uplifting newbies,
it should always be done in such a way that the end user has final,
knowledgeable say in each and every configuration decision. Not an
easy assignment, especially since the end user often must use a
configuration setup for a while, to gain experience with it, to determine
whither they like a feature or not. The trouble is, it is so easy to
think that you, as the distro's creator know what's best for the end
user. I hope to avoid this trap by suggesting to end users new to
Linux, several of the more flexible distros they can choose from, and then
showing configuration changes I have found useful in a step by step manner,
with full explaination of how they work. Not all distros even lend
themselves to being reconfigured in this manner, I will mention one
in particular, Ubuntu, near the end of section
6. Making more Virtual terminals
but I would refrain from jumping to that section, this page presents
you with an awfully lot of technical info, in order for you to understand
it all. For now here are some ludicrous examples of what I mean
by failing to allow the end user to make such choices.
Who ever thought half a dozen Virtual-Terminals was enough?...
Yet nearly every distro on the planet defaults to the basic six,
plus a GUI on seven. There's a much better way to do it, 23 VTs plus
the GUI on 24
The VT prompt should provide you with some useful status...
The one I show you how to build does, but to accomodate it,
it requires a two line prompt. This is one area that begs
for user customization, yet I seldom see anyone doing any...
Virtual-Terminals are programmable it is easy to place them in Console-Coma...
You as an alert user need to know how to return sanity to any of
the various Terminal-Bombs. I discuss this in depth.
Any, or even many, Virtual-Terminals can offer themselves up to Screen...
any instance of the Screen program can offer you limitless VTs via
the Screen programs Menu system for naming, and selecting a VT under
Screen's control, I show only one, VT-1, but you can have as many VTs
running Screen as you like.
Why do kernel errors clutter up your screen while you try to input commands?...
Many books claim you need to see them, yet X never bothers the end
user with them, so who is right? I say move those important, but
annoying missives to a special terminal of their very own, and to let you
know that message activity is occurring on VT23, we optionally sound the
VT23 console bell, set to a unique pitch, and duration to avoid confusing
it with the local console bell.
Who ever thought the X-server should run on power-up by default?...
Marketroids bent on making Linux look like Winders, that's
who! If a user wants to run the GUI, fine let them run startx.
The X window system is like any other highly complex application program,
as such the X server isn't as carefully designed as the system itself.
Maybe a user might even want to run X all the time, but that should never be
the default behavior of a distro, foisting defaults like X on
boot-up on an unsuspecting public, is tantamount to taking from them
any remnant of freedom to make, (or not make) such a choice.
Virtual-Terminals VTs...
can do so much.
Virtual-Terminals VTs...
can do so much.
Virtual-Terminals VTs...
can do so much.
Who ever thought half a dozen Virtual-Terminals was enough?... Get real,
my keyboard has 12 function keys, so I always boost VTs to include responding
to <Alt (F8 - F12)> evoking /dev/tty8
through /dev/tty12 usually through some getty
program of some stripe or other, of course it doesn't end there, while a
dozen VTs might be good enough for a server or a firewall that you rarely
ever plug in a video display monitor, and a keyboard, the machine that you
regard as your main workstation is a different matter. A properly
configured Linux box, running good stable hardware, overclockers need not
apply, :-) with an Uninterruptible Power Supply, (UPS) seldom, if ever,
goes down. Starting jobs that are intended to get very long in the
tooth is for the first time practical, with some common sense caveats, like
knowing about the "Lazy Unmount" switch -l (Kernel 2.4.11 or later) see
the umount manpage before you adopt this
mode of system usage.
Also the terminal restoration
program fixvt as of late 2007 was
available from...
it's 598 bytes long, and sports an md5sum
of 47dce715cf89e701e9c3ff97b8ccba7b
and it's been there since I first discovered it, last century, in exactly
the same file, byte for byte, any program that lasts that long without any
changes, in the computer world, evokes comparative mental imagery of the
Sphinx, or the Pyrimids, another very important program for promoting good
longterm VT health is stty especially in
conjunction with the Sane switch, as
in stty sane see the manpage
here too, also know something about Flow Control, a scroll-locked terminal
can appear indistinguishable from a dead machine, especially if you panic.
It is from that machine, your main workstation, that you remote into machines
all over your home, or your enterprise. That machine usually isn't just
one machine either, it's cabled with a KVM Switch (Keyboard Video, and Mouse
switch box) that switches to physically different machines. Regardless of
that consideration, machines that you regard as your main workstations,
should all get loads of VTs, not just the twelve I mentioned earlier, but
VTs that also respond to, assuming you have a good ole 101 key keyboard, the
<right Alt (F1 - F12)> key combos, evoking /dev/tty13 through /dev/tty24 from
all of those you can dedicate one or two of them to run the screen
program. This allows you a limitless number of terminals through a menu
selection process, that's always two combinatorial keystrokes away, plus the
effort to select a terminal from the menu. We are literally talking hundreds
of logins here. Since screen is the easiest to learn, I feel we
should do it first.
Note: None of this exercise requires root access, but you should be at
a Virtual Terminal, it will even run in an X Term
but I imagine there are all sorts of problems with doing
that. X will close a window with little regard to the tens, or
perhaps hundreds of logins under it, and probably Zombies those tasks.
X Terms come in all sorts of flavors, and with a host of special
features, any of which can interact with unpredictable results. If you
intend to use screen under X my advice is take it easy at first,
don't open too many terminals, or start very many applications, especially
apps that write to files, until you see how it goes.
OK This is a fun little exercise...
The absolute easiest way to learn how to tame screen is to copy out the
following ~/.screenrc even though
it's probably wrong for your machine, and run screen. Lines 5-7 give an
example walk through. To shut down all the terminals it opens up,
simply keep typing exit <Enter> until
you logout of all of them, simple as that.
# A working example of ~/.screenrc
#
# After placing this data in a file called $HOME/.screenrc run the screen
# program from a virtual terminal and then to access an interactive list
# of multiplexed terminals key in <Ctrl \> "
# to toggle last used screen key in <Ctrl \> <Ctrl \>
# to get the help screen key in <Ctrl \> ?
#
# """
#
# The wake up key sequence to access menu/controls defaults to <ctrl a>
# unfortunately <ctrl a> is used by many programs you are likely to
# run. Here are some of my experiments to replace <ctrl \> as the
# wake up key
#
# These are like starting screen up as ---> screen -e "\034\134"
# Note this works ---> escape "\034\\"
# and so does this ---> escape "^\\\"
# This does not do what I expected at all ---> defescape "\034\\"
#
#
escape "^\\\"
vbell off
term linux
# The following pre-assigns several terminals
screen
title "Beatnik Aumix"
screen telnet -l jk 10.0.0.132
title "Vagabond X10"
screen /home/jk/scripts/srg_mast_lst
title "SargeMasterlist"
# This...
# screen cat /home/system/Sarge/master_list | less -i -M -p zvbi_0.2.15-1_i386
# title "SargeMasterlist"
# ...does not work! I had to bundle the "cat /home/s..._i386" command into a
# bash script, and launch that see above screen /home/jk/scripts/srg_mast_lst
Machine Vagabond makes BSR X10
services available throughout my house, it is also my Print server,
and a few other ancillary services, that you do not have a machine
called Vagabond at that IP address,
is almost a certainty, so with
this ~/.screenrc on your machine, when
the screen program wakes up,
the Vagabond telnet login will fail.
As will the jk login following it, but
the terminal and its title will still be there. So this rc file is
kind of like the proverbial Bicycle-in-a-box with a rubber stamp impression
on the side that reads Some assembly required
This rc file is only a starting point for you to build on, and
customize according to your needs.
But the focus of this configuration section is on...
1. Am I someone you can trust?
Will my changes ruin your system?
If I said yes, would you try any of them? What if I said, Hey life is full
of risk, you can't even be certain that you will live out this day, let alone
have an insanely complex system like the computer sitting in front of you
continue to function normally after making major alterations in its most
sacrosanct configuration files? If you bought Novell, or RedHat, and you
think that the warranty, they provide you is something you can't live without
then I submit you are not willing to take any risks at all.
Back to my question,
Am I someone you can trust?
Will my changes ruin your system?
I will say this, I've been running my main workstation configured this way
for some time now, a Debian Sarge system, often with so many VTs in use
that I spill over into atleast one instance of the screen program.
As far as I can tell, both Fedora Core 2, Red Hat Linux
release 7.3 (Valhalla), work fine, as well as Debian Woody,
and as I mentioned earlier, Debian Sarge is my main work station,
gets lots of use at the terminal, and the at present, relatively new,
Debian Etch, on a Toshiba laptop, that dual boots Ubuntu.
However I will also say this, I present this material in a much different way
than you have come to expect. My approach is a series of very small,
self contained, and independantly testable configuration changes, mostly in
the /etc tree. Each of these changes
by itself constitute some small improvement over the way the operating system
was shipped. Thus I present this material in a way that is both a good
tutorial, and something that you can back out of, if you don't like the way a
change works. In fact if you think for one Pico-second that you can
get away with implementing my configurations, without making backups of the
files as they originally existed before you touched them, you are seriously
mistaken. You NEED to be ABLE to UNDO these things.
To throw caution to the wind in such matters flies in the face of common
sense, and good practice. Before you start, as Superuser e.g.
(root login) the very least you can do is the following shown below
in White:
The easiest way to enter those commands is, assuming you have the
GPM,(General Purpose Mouse) for console terminals installed,
you simply scoop up the commands shown above, by holding down the left
mouse button, while gliding the mouse cursor over the text, then, switching
to the Superuser console single click the right button, to dump the mouse
buffer, then press the enter key to execute the command.
There are some subtle problems that will arise from adding terminals that are
not included in distros following the prevailing wisdom, of you only need six
plus a GUI. There once was this Free (as in beer) device given away by many
merchants but far and away the widest dispersal vector was Radio Shack.
I'm speaking of course of the CueCat, a bar code reader, that auto-detected
many popular formats, and then imposed a very weak encryption of the output.
The CueCat plugged into the keyboard jack of your motherboard, and near that
plug, was a jack offered by the CueCat for you to plugin your
keyboard. Therefore technically, the CueCat was what we call a
keyboard wedge. Anyway they Dimentional the mother company is as
far as I can tell nolonger in the CueCat business, and after giving away
thousands of them, with free advertising software so that the CueCat would
take you right to the Web Site selling something that you
scanned. The thing is you give that many of a cool gadget away,
and some open source project will spring up to make it useful.
Actually several open source projects wrote a myriad of drivers, and programs
for the CueCat. One of them was simple perl script called cat.pl
it was fifty three lines of perl code, 925 bytes long, and had an MD5SUM of
018b2ee7ab0e31c72e65f1350689d160 cat.pl and the first comment read
"# This code is public domain code." as tiny as it was, it was probably the
most useful. The problem with the CueCat, is that as soon as it
decoded a valid scan, the lead bytes it output, were the key
sequence <Alt-F10> and an unmodified Linux workstation would
simply ignore it, but if you set up Ten or more Virtual-Terminals as soon as
it detected a valid bar code to scan, it issued the key sequence to take you
directly to VT-10 What to do What to do Well
you could modify my settings in /etc/inittab or you
could simply resign yourself to use the CueCat only when you are on VT-10 so
the CueCat's action of sending the key sequence <Alt-F10> is
no longer a problem. To date, this is the only issue of adequate
significance to make me aware of any problem arising out of the use of this
type of configuration, after two years of steady use, and yes, sadly, it's
in the devices firmware.
The source of much of what I am about to show you came to me as a mix of my
own experimentation, some stuff I read in books, and on the net, E-mail
answers to questions I've asked friends over the years, and the like. Linux
is a vast moving target, things that worked once, often have to be tweaked to
work today, and tomorrow who knows. One thing I can say with certainty, if
you find a good nugget of information on the net, don't simply save the URL,
the internet is far too fluid to rely on in that way, yes my site has been up
since 1999, but many move, or change their addy within a couple of years, so
my advice is save the page, or better yet, isolate the important stuff,
charts, graphs, examples, how-to text, and the like, and include the URL it
was sourced from, because if the site does stick around, they tend to make
corrections from time to time. Because of this I rarely list a URL that
carries information that is likely to change, here on my web site. Magazine
articles are an obvious exception. Once written they don't, or at least
shouldn't change much. So fixed is this form of media that The Linux Gazette
has been included in the more recent Debian distros Sarge, and Woody at least
anyway.
At some point starting up the X-server became organized, a real "C" program
was written, xinit to start the
X-server up according to dictates of one large configuration file
in /etc/X11 along with several smaller
ones in that general area. Still, with lots of command line switches
to choose from, environment variables, and the like, normal fare for anyone
conversant in the language of the Command Line Interface,(CLI)
was considered to be too much for someone used to the mouse driven
GUI,(Graphical User Interface) to grapple with, so they wrote a
rather temporary script called startx to
make it trivial to get the X-server up and running.
How temporary was it? This is an excerpt of the
actual /usr/X11R6/bin/startx script shipped
with Debian Etch (GNU/Linux 4.0),
Ubuntu Gutsy Gibbon (7.10), both of which are relatively
recent releases as of April 2008
#!/bin/sh
# $Xorg: startx.cpp,v 1.3 2000/08/17 19:54:29 cpqbld Exp $
#
# This is just a sample implementation of a slightly less primitive
# interface than xinit. It looks for user .xinitrc and .xserverrc
# files, then system xinitrc and xserverrc files, else lets xinit choose
# its default. The system xinitrc should probably do things like check
# for .Xresources files and merge them in, startup up a window manager,
# and pop a clock and serveral xterms.
#
# Site administrators are STRONGLY urged to write nicer versions.
#
# $XFree86: xc/programs/xinit/startx.cpp,v 3.16tsi Exp $
The Slackware version 7.1 excerpt of the
same /usr/X11R6/bin/startx script
bore a striking resemblance way back in December 1998, the names were changed
as X was under the auspices of the XConsortium, and XFree86, way back then as
differentiated from the modern form of X.org, so over the nine years of it's
existence that I have demonstrated here, probably many more, as I have
certainly had even older distros, that probably used this file, with the same
boilerplate advisory.
Then came Xdm which was an attempt to
keep even the login in the GUI realm. The acronym Xdm stood for
X Display Manager, later Gdm short for
Gnome Display Manager did the same job, with more emphasis on
security a generally agreed upon weakness of the X-server by notable folks
in the Cloak-n-Dagger industry. I suspect that if users are
proficient enough to understand the command line well enough to see programs
such as Xdm, and Gdm, as more of a nuisance than an aid, and have some
understanding of security issues, firewalls and the like, are probably
better off without the imposition of these programs. For one thing,
this forces the system to run with the GUI up all of the time, wasting CPU
and memory, and putting at risk any video driver bugs all of the time, as
opposed to only when you actually need the GUI.
So how do these programs startup, what is it in the initiating sequence that
makes them go? Xdm, and the more pedestrian work Gdm, have a startup
script of their very own, in /etc/init.d
Programs in this area can be run manually, by the superuser, but mostly
they are called through a series of symbolic links in the runlevel
directories. Not all distros put them in the same place, sad but
true. Miquel van Smoorenburg's Runlevel system, is
elegant simplicity, a form of algorithmic poetry, a half dozen predefined
runlevels, are in effect recipes for booting Linux with a subset of
components that will make it useful for six different walks of life.
The components that are selected to run, and the order they are loaded,
are crucial, for that walk of life to properly perform its task.
Off the /etc/ directory are, assuming a
properly implemented Miquel van Smoorenburg's Runlevel system,
several directories of the form rcX.d where
the X is the numerical label of the
runlevel. They are filled with symbolic links, all pointing to script
files in /etc/init.d another special
directory that is also part of the runlevel system. The
naming convention, special letters, and numbers, in the names of the
symbolic links themselves dictate the order or sequence of the
startup, and shutdown, of services which allow this simple, easily
maintained, system to effortlessly switch from one runlevel, to another,
by simply calling a command line program to goto another runlevel.
The details of ordering which service starts, when, or which shuts
down, and when, is all controlled by the symbolic links in
those "rcX.d" directories.
It is this coded naming convention that makes it possible for a
program, telinit to automate the whole
thing, when you think about it, it's a thing of beauty. Since the
naming convention follows explicit rules, it is possible for third party
programs to interactively, or autonomously change the runlevel order,
and or contents. Indeed many such programs have already been written,
often as a GUI wrapper to assist the user in setting the runlevels.
The following is a README that is part of the built in documentation that
goes into all Debian installs nowadays, I urge you to read it.
As I mentioned earlier not all distros put
the "rcX.d" runlevel symlink repositories
in the designated prescribed System-V location. System-V, pronounced
"System five" was a code fork long ago established Unix tradition in
two directions System-V, and BSD. Today System-V is synonymous with a
Runlevel based design, and in the Open Source GPL world that usually means
Linux of some sort, and BSD conversely is synonymous with a hard coded script
driven start up. System-V was created under the auspices of none other
than AT&T, AKA TPC, The Phone Company
this has been given as the reason there are seven runlevels, because AT&T
felt that was what they needed from an operating system that was to perform
telephone related tasks. I suspect you could add more runlevels,
although scripting written for seven wouldn't deal with any you add, since
the world has standardized on seven. I also suspect for more or
less the same reason, Miquel van Smoorenburg's implementation of
the System V Runlevel system was largely an effort of adhering to a
previously existing standard, rather than inventing anew.
keeping with the need for compatibility with
from long ago established Unix tradition, in keeping with the need for compatibility with
Miquel van Smoorenburg's System V Runlevel system,
the "rcX.d" directories have atleast some representation, even if only
a symlink to the real thing,
at /etc/rc1.d -thru- /etc/rc6.d a
distro that places them in weird places should provide symlink directories
/VT/README.runlevels.html
Mostly for compatibility with Miquel van Smoorenburg Runlevel
system, which defines the "rc" directories as follows
the "rc" directories have atleast some representation, even if only
a symlink to the real thing,
at /etc/rc1.d -thru- /etc/rc6.d a
distro that places them in weird places should provide symlink directories
3. /etc/issue making VTs self identifying
Many Linux distros fail to recognize the value of having a blank login screen
identify which Virtual Terminal is being presented to you. First of all
I need to mention something covered exhaustively in the next section
namely navigating VTs. You can jump directly to a particular VT by
using the key combo <left Alt Fn> where n is
one of the Function keys at the top row of a 101 key keyboard. This
gets you to any of the first 12 VTs. To jump to
VTs 13 to 24 is a bit more involved, but the simple case is
if you are not in the GUI, you use the key
combo <right Alt Fn> where n is
F1 for VT13, F2 for VT14, and so on up to
F12 for VT24. Basically as long as you're at the
VT console these key mappings work properly. In addition to that
you can jump to the VT to the right, or to the left, of where you are
now, by using the left/right arrow keys in the arrow key cluster of
a 101 key keyboard, by pressing <left Alt Left-arrow>
or <left Alt Right-arrow> respectively. Now this
is where it's real important to have terminal ID reporting turned on.
That way, a blank login tells you which VT it is, no guesswork.
CueCat's as I mentioned earlier, send
an <left Alt F10> at the beginning of every
successful barcode read, so you need to select VT10 you use the CueCat.
And if you are using the left/right arrow method to
get there, a handy way to do it, having blank logins identify themselves
really makes a difference. To turn on this feature we use
the "\l" switch inside
the /etc/issue file. The format of the
switches used in this file are covered in the Getty manpage. Gettys
come in many varients, getty, agetty, or, mingetty, to name a few, I list
the switches you can place in that file, here to give you soe idea of the
flexibility this mechanism offers.
ISSUE ESCAPES
mingetty recognizes the following escapes sequences which
might be embedded in the /etc/issue file:
\d insert current day (localtime),
\l insert line on which mingetty is running,
\m inserts machine architecture (uname -m),
\n inserts machine's network node hostname (uname -n),
\o inserts domain name,
\r inserts operating system release (uname -r),
\t insert current time (localtime),
\s inserts operating system name,
\u resp. \U the current number of users which are cur-
rently logged in. \U inserts "n users", where as
\u only inserts "n".
\v inserts operating system version (uname -v).
EXAMPLE
"Linux eos i386 #1 Tue Mar 19 21:54:09 MET 1996" was pro-
duced by putting "\s \n \m \v" into /etc/issue.
As I said many Linux distros fail to recognize the value of having
a blank login screen, cheif among them
is RedHat and spawn
of RedHat Fedora Core n
seem rather inflexible in this area, to be fair they may view it as
a security issue, although restricting local consoles seems a bit much.
Happily however it's trivial to remedy, you edit
the /etc/issue file adding
the \l switch
need I mention to edit anything in
the /etc tree requires root access.
Before
/etc/issue unaltered
Red Hat Linux release 7.3 (Valhalla)
Kernel \r on an \m
Blank login
Red Hat Linux release 7.3 (Valhalla)
Kernel 2.4.18-3 on an i686
gypsy login:
After
/etc/issue with /l switch
Red Hat Linux release 7.3 (Valhalla)
Kernel \r on an \m at terminal \l
Blank login/w term ID
Red Hat Linux release 7.3 (Valhalla)
Kernel 2.4.18-3 on an i686 at terminal tty3
gypsy login:
In this youthful varient of Linux the file /etc/rc.d/rc.S contains the
following segment...
# Setup the /etc/issue and /etc/motd to reflect the current kernel level:
# THESE WIPE ANY CHANGES YOU MAKE TO /ETC/ISSUE AND /ETC/MOTD WITH EACH
# BOOT. COMMENT THEM OUT IF YOU WANT TO MAKE CUSTOM VERSIONS.
echo > /etc/issue
echo Welcome to Linux `/bin/uname -a | /bin/cut -d\ -f3`. >> /etc/issue
echo >> /etc/issue
echo "`/bin/uname -a | /bin/cut -d\ -f1,3`." > /etc/motd
...so rather than change the /etc/issue file,
as I instruct you to do in beginning of this treatise, I rewire the code that
rewrites that file to begin with, see below...
echo > /etc/issue
echo -n Welcome to Linux `/bin/uname -a | /bin/cut -d\ -f3`. >> /etc/issue
echo " "\\l >> /etc/issue
echo >> /etc/issue
echo "`/bin/uname -a | /bin/cut -d\ -f1,3`." > /etc/motd
...that finishes the terminals so you can see which one they are, if no one
is as yet logged in.
4. Keys for Navigating between 23 VTs,
in and out of a GUI, and screen
There are very few sources of info that even mention how to move the
VT that activates the X-server GUI, http://www.linuxjournal.com/article/5303
mentions it, as well as a book here or there, on administering Linux, but
when it comes to switching between VTs while out of the X-server, I have yet
to see one that get's all of it right.
o- While in the X-server GUI, to escape to bare
VTs 1 - 12 you press
<Ctrl L-Alt F1 -through- F12> -or- <Ctrl R-Alt F1 -through- F12>
will exit the GUI to the VT of your choice, Almost! The caviat is that
there's no way to reach VTs 13 -through- 23, the GUI simply
interprets both the Left and Right Alt key combos the same way, and places
you at a VT corresponding to
<Left Alt Fx> where x is 1-thru-12
Only!
o- Books, the dead tree kind, and many a HowTo on the net,
tell you to use <Ctrl L-Alt F1 -through- F12>
universally whither using it to exit the GUI to a VT, or hopping from one VT
to another. This info is DEAD WRONG! That the VT keyboard handler
either ignores the left control key in combintaion with Left Alt, or
treats the combo the same as the Left Alt key alone, so it is
in this mistaken view that it is alright to teach fledgling Linux users
to use <Ctrl Left Alt Fx> whither you're in the GUI or
not, saving them the effort of learning a special key combo for each
environment, GUI, and VT. The problem arises when you turn on
VTs 13 -thru- 24, which use the Right Alt key, and
while in the VT CLI, (Virtual Terminal Command Line Interfaced)
environment no such substitution for <Ctrl Right Alt Fx>
is wired to VTs 13 -thru- 24
o- The proper way to remember and use it is...
When in GUI:
<Ctrl Left Alt Fx> for x=1-12 only.
When in CLI: <Left Alt Fx> for x=1-12
and <Right Alt Fx> for x=13-24 MEMORIZE THIS, USE IT, MAKE IT SECOND NATURE.
5. Can X activate VTs 13-thru-23?
And should it be mapped to do so?
Warning This is Experimental!
This whole thing of the X-server not fully supporting underlying functionality
of the Virtual Terminals, seems to be a matter of one Opensource Group not
being aware of what the other is doing. Can it be made right? I will answer
that with a qualified yes. You see this goes right back to the question, can
you trust me. The kind of tweaking I'd have to do to make the X-server work
properly, gets into a series of changes that I would like to pose a question
to the folks that are maintaining the X-server, before I recommend it to
anyone, failing that, I'd like to run with it for a while to make sure it all
works. But it seems it can be done. Here's an experiment that sort of
proves it's possible, atleast under Debian Sarge. Note: This is experimental
I will not be responsible for anything you do after reading my site, it goes
without saying that you are REALLY ON YOUR OWN with an experimental setup!
If you are curious enough to try this, please back everything up, or do your
experimentation on a sacrificial machine, like that one you pulled out of the
dumpster last weekend. It is assumed that you've installed a well rounded
Linux distro on such a machine, gotten X working, and laied in my settings
described in this section, to give you an unbroken string of 23 virtual
terminals, with number 24 being the X window GUI. The following experimental
setup is based on Debian Sarge, though others will probably work.
First without X running, edit the
file: /etc/X11/xkb/compat/xfree86 Change
the following item...
...and then run startx.
When it is fully operational, press <Ctrl Alt F7> and you
should go to VT7 After you have observed that this is in fact working,
press <Right Alt F12> now you should be back in the
X-server. OK now press the key combination that activates our
experimental VT23, that being <Ctrl Alt F11> and shazam,
it works! As you'd expect <Right Alt F12> gets you
back in X.
Working backward through the keycode logic, your next stop is probably the
file: /etc/X11/xkb/symbols/srvr_ctrl Now go
looking for a substring
called: XF86_Switch_VT_ and study the
logic around them. If you search
from /etc/X11/xkb recursively as follows:
grep -r -i "XF86_Switch_VT_" * | less
there are many more places where this substring appears, and that means if
I were to do it, I'd need ample time, motivation, and perhaps feedback from
X.org as to what all else will be effected by this. If you think you would
like to tackle getting X to recognize VTs addressable by both Left-ALT and
Right-ALT this may be a starting place, under Debian Sarge, and Fedora C2
there are several a doc files, do ls -al /etc/X11/xkb/READM* to get the
list. One in particular /etc/X11/xkb/README near the end, mentions the
complete specification on http://www.x-docs.org/XKB/XKBproto.pdf
6. Making more Virtual terminals
the simple case 11 with the GUI on VT7
This one is so simple that if you don't atleast do this one, you'll wish
you had. No mucking about down in the innards of X, in fact
we intentionally leave the X-server at VT7, for now, I save that
sort of thing for the industrial strength, ultra heavy
duty advanced user modifications that I show later.
No really, it is that simple, what you do is, as root, you edit the
file /etc/inittab with what ever simple
text editor you regard as your favorite. You are looking for a series
of automatically self re-spawning calls to the program responsible for the
default VTs,(Virtual Terminals) your system has to begin with.
Usually VT1 -thru- VT6 and usually this hunk of script code
is near the end of the inittab file. That program, the VT maker,
is some form of getty short for
Get-TTY. I can't tell you what exactly you're looking for, because
there are several kinds of these programs, that all do pretty much the same
thing, some do serial lines, others are integrated into another package, and
the like. One underlying common thread that I have observed seems
to be that what ever its name, it has the term getty embedded in the
name, some examples include mingetty, agetty, vgetty, mgetty, and fgetty.
Here's a way to help you to spot which one your system is using...
ps axw | grep -i getty
...execute the above command to reveal the true getty I demonstrate
by experiment what happens at every step of this unfolding configuration
project. I don't generally recommend that you repeat the
experiment that shows what happens when you cause the X-server to use
a VT that's already spoken for, but don't worry, I give you
ample Kids... Don't do this at home!
type of warning. It isn't reasonable for me to cover all distros,
I have to leave some of you out, however many of them, with a little
thought, and study of what's being done, may find the chore of modifying
my instructions for one of the three that I do show, to fit your particular
distro, both rewarding, and enjoyable. Lets face it sooner or later
you're going to have to learn how to skull this sort of thing out
anyway, and short of offering a few very general guide lines here or
there, I don't believe one can really teach the art of Skulling.
One thing I do hope to instill in you, is good practise when it comes to
documenting what you do, and how you came to decisions along the way.
Good Luck.
Slackware-version 7.0.0
Under Slackware-version 7.0.0 with Kernel 2.2.13 on a machine called Slacker
This is an old enough distro that things go back to a simpler time when Linux
was young. The runlevels are for instance Hard-Coded shell scripts, and as
in modern Linux, these scripts are mostly coded by Miquel van Smoorenburg who
later went on to write the Symbolic Linked RunLevel system most folks are
familiar with today. I will revisit this when I show you a piece of code that
needlessly rewrites the /etc/issue file,
everytime you reboot.
The file /etc/inittab like all the other distros is where all the VTs are
spawned, but it's quite a bit different, and yet in some ways the same.
(Late breaking item Ubuntu doesn't use /etc/inittab or the
standard runlevel control system that Miquel van Smoorenburg wrote)
The first six terminals VTs 1 - 6 are spawned as follows leaving VT 7 for the
X-server GUI,(Graphical User Interface) shown in purple.
# The getties in multi user mode on consoles an serial lines.
#
# NOTE NOTE NOTE adjust this to your getty or you will not be
# able to login !!
#
# Note: for 'agetty' you use linespeed, line.
# for 'getty_ps' you use line, linespeed and also use 'gettydefs'
# Run gettys from Virtual Terminals 1 - 6 activated by <Left Alt F1 - F6>
c1:1235:respawn:/sbin/agetty 38400 tty1 linux
c2:1235:respawn:/sbin/agetty 38400 tty2 linux
c3:1235:respawn:/sbin/agetty 38400 tty3 linux
c4:1235:respawn:/sbin/agetty 38400 tty4 linux
c5:1235:respawn:/sbin/agetty 38400 tty5 linux
c6:12345:respawn:/sbin/agetty 38400 tty6 linux
Continuing in the Slackware example, to get the simple case 11 VTs with
the GUI still on VT7 you would add the following...
Don't forget to actually flesh out the sequence, that is don't merely
parrot what I wrote in the example.
# Run gettys from Virtual Terms 8 - 12 activated by <Left Alt F8 - F12>
c8:1235:respawn:/sbin/agetty 38400 tty8 linux
c9:1235:respawn:/sbin/agetty 38400 tty9 linux
- - - sequence is filled in as you'd expect - - -
c11:1235:respawn:/sbin/agetty 38400 tty11 linux
c12:1235:respawn:/sbin/agetty 38400 tty12 linux
Debian-version Sarge
Under Debian-version Sarge (3.1) with Kernel 2.4.27-2-386 on a
machine called Thinman. This is a new enough distro that it uses a
Symbolic Linked RunLevel system which was the brainchild of
Miquel van Smoorenburg. As I said earlier Debian loves to
sprinkle in loads of comments in its configuration files, and this excerpt
of the /etc/inittab emphasizes my point.
# /sbin/getty invocations for the runlevels.
#
# The "id" field MUST be the same as the last
# characters of the device (after "tty").
#
# Format:
# <id>:<runlevels>:<action>:<process>
#
# Note that on most Debian systems tty7 is used by the X Window System,
# so if you want to add more getty's go ahead but skip tty7 if you run X.
#
# Run gettys from Virtual Terminals 1 - 6 activated
by <right Alt F1 - F6>
1:2345:respawn:/sbin/getty 38400 tty1
2:23:respawn:/sbin/getty 38400 tty2
3:23:respawn:/sbin/getty 38400 tty3
4:23:respawn:/sbin/getty 38400 tty4
5:23:respawn:/sbin/getty 38400 tty5
6:23:respawn:/sbin/getty 38400 tty6
Still in Debian Sarge:
these are the VT getty allocations that you add in this simple version
of making more VTs shown below in Yellow.
# Run gettys from Virtual Terms 8 - 12 activated by <Left Alt F1 - F12>
8:23:respawn:/sbin/getty 38400 tty8
9:23:respawn:/sbin/getty 38400 tty9
10:23:respawn:/sbin/getty 38400 tty10
11:23:respawn:/sbin/getty 38400 tty11
12:23:respawn:/sbin/getty 38400 tty12
RedHat 7.3 (Valhalla)
This is the default case for RedHat 7.3 (Valhalla)
it provides the first six terminals activated
by <Left Alt F1 - F7> shown
below in Purple.
# Run gettys in standard runlevels
1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
4:2345:respawn:/sbin/mingetty tty4
5:2345:respawn:/sbin/mingetty tty5
6:2345:respawn:/sbin/mingetty tty6
These are the VTs that you add in for RedHat 7.3 (Valhalla)
it provides the next five terminals activated
by <Left Alt F8 - F12> shown
below in Yellow.
Everything that all other distros I have seen so far, accomplished in
the single file /etc/inittab is now
performed under Ubuntu as a series of very short script files in a
subdirectory Ubuntu calls /etc/event.d that
attempts to accomplish the same functionality as the original
Miquel van Smoorenburg's Runlevel system, but apparently without
actually using any of his code. All the System V compatible runlevel
commands have been replaced with a Canonical Ltd Copyrighted
version. Even more interesting, Ubuntu a trademark of Canonical Ltd
which claims to be Debian based, appears with regularity along side Miquel's
name in the bug lists, and if you look in your man pages, of other
Normal distros of Linux they haven't talked about bugs now for
years, because there haven't been any. Modern distros don't even bother
with puting the BUGS: None phrasing in the manpage, that is
until Canonical Ltd's Ubuntu, with its odd duck
replacement for Miquel's time tested runlevel code. Anytime you build
any reverse engineered clone of an established piece of software, you run the
risk of introducing new bugs. This is especially true with cloning low
level primitives that support mountains of other software written, and
debugged hence the originals inception.
"So" the wisdom goes you'd better have an extremely good
reason for tinkering with an established pillar before you begin, and as a
matter of good practise you need to document what you've done thoroughly, for
the benefit of future programmers, especially if what you've done, can fail
on your platform, and yet work properly on other existing, widespread
systems in use at the time. I haven't found any such document, and
I did a fairly careful search, though admittedly not an exhaustive one,
I certainly haven't come across anything on a par with the man page for
inittab(5) that comes with every Normal Linux distro out there.
Be that as it may, I will attempt to show what happened when, after a lot of
experimentation, I managed to get extra VTs to come to life under
Ubuntu a trademark of Canonical Ltd. To begin with I think
it would be instructive to show you the directory in question,
the ls command is shown in White, and
the listing results in Blue-Green.
If you are by now familiar
with /etc/inittab and some of what
it does, this goes without saying that you're the studious type, you're
the one to read several chapters ahead in the textbook, before getting
seriously under the skin of the teacher, and in keeping with the
Modus Operandi, you've already deduced, that if the above filenames
are any indication of their function, that this directory is where
that functionality is. And you'd be right, remember in a normal
distro's /etc/inittab there were sections
where line after line went something like...
6:23:respawn:/sbin/getty 38400 tty6
...to setup the VT / getty? Well under Ubuntu the Smoorenburg
Franken-clone equivelent uses a whole file to accomplish the same thing,
here's Ubuntu's entry for tty6 shown here in Purple...
# tty6 - getty
#
# This service maintains a getty on tty6 from the point the system is
# started until it is shut down again.
start on runlevel 2
start on runlevel 3
stop on runlevel 0
stop on runlevel 1
stop on runlevel 4
stop on runlevel 5
stop on runlevel 6
respawn
exec /sbin/getty 38400 tty6
...So I added two of my own, VT9, and VT13. VT9 was
chosen because VT1 - VT6 plus the GUI at VT7,
plus an error window on VT8, hence VT9 was the next available. As for
the rational of VT13 for the next test, was that I wanted to know if
the second rank of VTs worked under Ubuntu. Shown below are my
modifications. First VT9 shown in Yellow.
# tty9 - getty
#
# This service maintains a getty on tty9 from the point the system is
# started until it is shut down again.
start on runlevel 2
start on runlevel 3
stop on runlevel 0
stop on runlevel 1
stop on runlevel 4
stop on runlevel 5
stop on runlevel 6
respawn
exec /sbin/getty 38400 tty9
Next VT13 shown in Yellow.
# tty13 - getty
#
# This service maintains a getty on tty13 from the point the system is
# started until it is shut down again.
start on runlevel 2
start on runlevel 3
stop on runlevel 0
stop on runlevel 1
stop on runlevel 4
stop on runlevel 5
stop on runlevel 6
respawn
exec /sbin/getty 38400 tty13
After I laid these changes in, and rebooted Ubuntu, both new terminals
worked, VT9 worked perfectely, where as VT13 worked if you could
get to it. Pressing <right Alt (F1 - F12)>
key combos, has the exact same effect as pressing
<left Alt (F1 - F12)> key combos, completely
locking out direct combinatorial key access to the second rank of VTs.
There are still a couple of ways to access VT13 one is, repeatedly press
<left Alt (Left arrow or Right arrow)>
key combos, until you get there. The other is to from an active Login
simply execute chvt 13 for example
to switch to VT13, so yes VTs 13 - 24 could in theory be made to work but
I have to wonder how many more things they've screwed up, and how fixing
those things will become vulnerabilities themselves. In My skulling on
the internet I noticed people asking for help fixing things that would
have been dirt simple, if were not for Ubuntu's deliberate nonstandard
needless quirkiness. The answers they were getting were downright
absurd, and clueless. It is for these and other reasons I cannot
recommend that anyone use Ubuntu, unless there is simply no other solution,
I am quite certain that in the long term you will not be happy.
7. Making lots more Virtual terminals
advanced case 23 with the GUI on VT24
Continuing on with my configuration, I lay ther ground work for moving
the GUI from VT7 to VT24, this will permit us to
open up a uniform block of 23 contiguous VTs, but for now we
leave VT7 unchanged, as it will allow me to show that step by
experiment, and it will remain right up to the very end reversible.
Slackware first:
This excerpt of the /etc/inittab shows the
default first six VTs being instantiated in purple.
# The getties in multi user mode on consoles an serial lines.
#
# NOTE NOTE NOTE adjust this to your getty or you will not be
# able to login !!
#
# Note: for 'agetty' you use linespeed, line.
# for 'getty_ps' you use line, linespeed and also use 'gettydefs'
# Run gettys from Virtual Terminals 1 - 6 activated by <Left Alt F1 - F6>
c1:1235:respawn:/sbin/agetty 38400 tty1 linux
c2:1235:respawn:/sbin/agetty 38400 tty2 linux
c3:1235:respawn:/sbin/agetty 38400 tty3 linux
c4:1235:respawn:/sbin/agetty 38400 tty4 linux
c5:1235:respawn:/sbin/agetty 38400 tty5 linux
c6:12345:respawn:/sbin/agetty 38400 tty6 linux
Still Slackware:
Our previous experiment, this excerpt of
the /etc/inittab shows the simple case of
adding VT8 - VT12 being instantiated in Blue-Green.
leaving VT7 available to the GUI for testing.
# Run gettys from Virtual Terms 8 - 12 activated by <Left Alt F8 - F12>
c8:1235:respawn:/sbin/agetty 38400 tty8 linux
c9:1235:respawn:/sbin/agetty 38400 tty9 linux
c10:1235:respawn:/sbin/agetty 38400 tty10 linux
c11:1235:respawn:/sbin/agetty 38400 tty11 linux
c12:1235:respawn:/sbin/agetty 38400 tty12 linux
Still Slackware:
Brings us up to the present, in the experiment we are about to perform, this
excerpt of the /etc/inittab shows the
advanced case where we add VT13 - VT23 to be instantiated
in Yellow. leaving both VT7 and VT24 available
to the GUI for experimental testing.
# Run gettys from Virtual Terms 13 - 24 activated by <Right Alt F1 - F12>
c13:1235:respawn:/sbin/agetty 38400 tty13 linux
c14:1235:respawn:/sbin/agetty 38400 tty14 linux
c15:1235:respawn:/sbin/agetty 38400 tty15 linux
c16:1235:respawn:/sbin/agetty 38400 tty16 linux
c17:1235:respawn:/sbin/agetty 38400 tty17 linux
c18:1235:respawn:/sbin/agetty 38400 tty18 linux
c19:1235:respawn:/sbin/agetty 38400 tty19 linux
c20:1235:respawn:/sbin/agetty 38400 tty20 linux
c21:1235:respawn:/sbin/agetty 38400 tty21 linux
c22:1235:respawn:/sbin/agetty 38400 tty22 linux
c23:1235:respawn:/sbin/agetty 38400 tty23 linux
# note: vt 24 is left un-configured, as it belongs to X windows
# c24:1235:respawn:/sbin/agetty 38400 tty24 linux
Under Debian-version Sarge (3.1) with Kernel 2.4.27-2-386 on a
machine called Thinman. This is a new enough distro that it uses a
Symbolic Linked RunLevel system which was the brainchild of
Miquel van Smoorenburg. As I said earlier Debian loves to
sprinkle in loads of comments in its configuration files, and this excerpt
of the /etc/inittab emphasizes my point,
in the default VT getty allocations shown here in Purple.
# /sbin/getty invocations for the runlevels.
#
# The "id" field MUST be the same as the last
# characters of the device (after "tty").
#
# Format:
# <id>:<runlevels>:<action>:<process>
#
# Note that on most Debian systems tty7 is used by the X Window System,
# so if you want to add more getty's go ahead but skip tty7 if you run X.
#
# Run gettys from Virtual Terminals 1 - 6 activated
by <right Alt F1 - F6>
1:2345:respawn:/sbin/getty 38400 tty1
2:23:respawn:/sbin/getty 38400 tty2
3:23:respawn:/sbin/getty 38400 tty3
4:23:respawn:/sbin/getty 38400 tty4
5:23:respawn:/sbin/getty 38400 tty5
6:23:respawn:/sbin/getty 38400 tty6
Still in Debian Sarge:
In the previous exercise, these are the VT getty allocations that you added
in the simple version of adding VTs shown below in Blue-Green.
# Run gettys from Virtual Terms 8 - 12 activated by <Left Alt F1 - F12>
8:23:respawn:/sbin/getty 38400 tty8
9:23:respawn:/sbin/getty 38400 tty9
10:23:respawn:/sbin/getty 38400 tty10
11:23:respawn:/sbin/getty 38400 tty11
12:23:respawn:/sbin/getty 38400 tty12
Still in Debian Sarge:
Now in this the advanced exercise, these are the VT getty allocations that
you are about to add, my example configures gettys for VT13 - VT23 shown
below in Yellow.
# Run gettys from Virtual Terms 13 - 23 activated by <Right Alt F1 - F12>
13:23:respawn:/sbin/getty 38400 tty13
14:23:respawn:/sbin/getty 38400 tty14
15:23:respawn:/sbin/getty 38400 tty15
16:23:respawn:/sbin/getty 38400 tty16
17:23:respawn:/sbin/getty 38400 tty17
18:23:respawn:/sbin/getty 38400 tty18
19:23:respawn:/sbin/getty 38400 tty19
20:23:respawn:/sbin/getty 38400 tty20
21:23:respawn:/sbin/getty 38400 tty21
22:23:respawn:/sbin/getty 38400 tty22
23:23:respawn:/sbin/getty 38400 tty23
8. Move GUI VT via /usr/bin/X11/startx
Now the time has come to roll up our ethereal shirtsleeves, and begin to
experiment with placing the X-server on different virtual terminals.
All of this is a moving target, the XFree86 organization ended its life when
a well meaning someone made a miniscule change to the open source license
to give credit to some under recognized people within the organization,
making XFree86 no longer GPL compatible, as a direct result distro after
distro refused to include the new version 4 in their software. Others
erected X.org and the race was on to catch X.org up to the high standard
that XFree86 had attained, without using any of XFree86's code. You
need to experiment with this to find out what works, because frankly
I can't begin to predict how these varaibles will be used until this
settles out.
The file /usr/bin/X11/startx they
haven't yet fleshed out the variables, what was to become the
file /usr/X11R6/bin/startx had a variable
called defaultserverargs="" was handled
with a little more care, so that my setting it
to defaultserverargs="vt24" had several
extra chances to overide the VT7 default, but in Slackware 7.0.0 the
variable serverargs="" lacks this additional
logic. However after studying the script, I timidly
set serverargs="vt24" and it seemed to
work. As an additional test I temporarily left VT7 unassigned,
(no getty instantiation of VT7)
and ran startx it placed the
GUI on VT24, then I ran it again shown here in White,
as follows...
startx -- vt7
...and sure enough, it placed the GUI on VT7. I now have the
X-server defaulting to starting up on VT24, and working properly on VT24,
yet still responding to command line directives, so now we can dispense
with having to reserve VT7 for the GUI X-server.
Next I assigned a Getty to VT7:
First Slackware:
This excerpt of the /etc/inittab shows the
assigning of VT7 to a getty for
the advanced case configuring code highlighted in Yellow. leaving
only VT24 available to the X-server GUI
# Run gettys from Virtual Terms 1 - 12 activated by <Left Alt F1 - F12>
# Run gettys from Virtual Terms 13 - 23 activated by <Right Alt F1 - F12>
c7:12345:respawn:/sbin/agetty 38400 tty7 linux
# note: VT24 is left un-configured, as it belongs to X windows and if you're
# on a VT, you access the GUI by pressing <Right Alt F1 - F12>
# c24:1235:respawn:/sbin/agetty 38400 tty24 linux
Next the Debian case:
Once again an excerpt of /etc/inittab shows
code to assign VT7 to a getty in
yellow highlight. leaving only VT24 available to
the X-server GUI
In keeping with Debian's verbose, and useful commenting of script files,
I flank both sides with useful comments about occupying VT7, and
setting VT24 as the default VT for the GUI X-server. You should
choose where best to place these comments. Also note that assigning
the VT7 getty late in the game, i.e. not in numerical order, will only
affect the PID,(Process ID.) as far as I know nothing else is
affected if you activate it out of order, to maintain the flow and
readability of the /etc/inittab script.
# Run gettys from Virtual Terms 1 - 12 activated by <Left Alt F1 - F12>
# Run gettys from Virtual Terms 13 - 23 activated by <Right Alt F1 - F12>
7:23:respawn:/sbin/getty 38400 tty7
# Here I reserve tty24 for the X-server
# 24:23:respawn:/sbin/getty 38400 tty24
# Note a change in the file /usr/X11R6/bin/startx on line 24 the parameter
# defaultserverargs=""
# ...was changed to...
# defaultserverargs="vt24"
# to move the X-server from VT7 to VT24
# (many thanks to Evan A for skulling the following out for me)
# also if you do use GDM,(Gnome Display Manager) /etc/X11/gdm/gdm.conf
# needs the parameter FirstVT=7 fixed up appropriately too.
Now that VT7 has a Getty:
Re-boot to make it so...
...and again I ran startx Now the
GUI was available via. <Right Alt F12> which
is VT24. Exactly what we set out to do.
Now for some dangerous experimentation.
Kids... Don't do this at home!
You have been warned, I know many ways to deal with out of control
consoles, I can if necessary sneak in through the LAN to fix a borked
up console, without subjecting the system to a less than orderly shutdown.
After shutting down the X-server, I then ran...
startx -- vt7
If you are alert, you will realize that this will attempt to start the
X-server on a VT that is already occupied by the aforementioned getty that
I just assigned to VT7... You're probably thinking something's
got to break. And you'd be right, break it does...
...at this point I had a GUI, that had no keyboard, only the mouse. I tried
all sorts of things on the keyboard, but it appeared utterly dead. I then
used the mouse to shut down the X-server, which it did, and I was back at VT2
the same terminal that launched X under VT7. So being curious, I pressed
<Left Alt F7> and there was a bare login screen, with a considerable
number of nonsensical keystrokes typed in at the login prompt. Additional
work at the keyboard revealed the keyboard was in the wrong mode,
as X changes the mode of the keyboard. There are elegant things one
can do to restore the keyboard back to sanity, but
running ps axw to get
the PID of the Getty that was VT7, and then
kill it, since it is a self re-spawning program, it re-spawned in the right
mode, and that was that. I'd read some where that is a really bad thing
to do, to run X in a VT that is already occupied by a Getty and now I know
what they mean. First thing that goes wrong is that the keyboard focus
remains on the Getty Terminal, and as the X-server starts up it switches the
keyboard mode, so things are now so totally borked that this instantiation
of X-server is doomed to a short life of failure.
There is yet one final detail to complete the scene.
The file /etc/securetty begins as
follows...
# This file defines which devices root can log in on.
# These are the ttys on the physical console:
console
tty1
tty2
...it needs fleshing out, add specifiers for all the new ttys you've just
added to the system, probably tty8 - tty24 You'll find that
Debian is very generous with these default terminal settings, probably no
changes are necessary.
9. Changing GUI VT under GDM and
similar kindred spirits.
Warning This is Experimental!
About a quarter into the
file /etc/X11/gdm/gdm.conf you will see
the following directives...
# Automatic VT allocation. Right now only works on Linux. This way
# we force X to use specific vts. turn VTAllocation to false if this
# is causing problems.
FirstVT=7
VTAllocation=true
...changing FirstVT=7 to something else
seems to work on the next startup/restart
of GDM but other than really checking to
see if it works I've gone no further, much more testing is needed, an auto
restarting X is problematic even in the best of
circumstances anyway, and X itself tends to pick up cruft,
processes that fail to terminate properly, memory leaks, temp files
that aren't disposed of, are all hallmarks of GUI technology, I've shown
you what can happen if you hand off X to an already active terminal
and if anything goes wrong in the hand off, that is exactly what's likely to
happen. Now we consider GDM set to a different terminal, if there's
another directive somewhere, that GDM chooses to override our FirstVT
directive, say on a restart, you could loose control of your workstation.
The CLI is clean, unambiguous, an intelligent agent, YOU, are in
control of everything, by contrast a GUI does so much stuff behind the scenes
that when something anomalous happens, something that an alert human would say
"hey wait a minute, what just happened there," the GUI never questions it, so
the error never gets fixed, and eventually quite often produces a cascade of
errors that bring the whole GUI down. Note: it doesn't very often bring
down the system as a whole, just the GUI, so you can often
restart X to go on, but then the file cruft never gets fixed.
If on the other hand, X is issued a command to do an organized
shutdown, it has mechanisms to resolve at least some of those errors, but
only if X is still alive, once it dies, the memories of the locus
of cumulative errors is gone forever, as well as information on how to
resolve them. GDM tends to never give X a proper rest.
CLI inside the GUI as a safety net. * Best Practices
I rarely run X anywhere but my workstation, and I tend
to launch application programs from the command line, in an Xterm often
followed by an & symbol which
backgrounds the application to free the terminal for other work.
This has several advantages, for one thing, you get to see error messages in
real time, as they happen, also most applications like to be told what to do,
and how to act, thus instead of clicking on
the xine icon and then diving into a dozen
menus, clicking like mad to restart some cute car crash clip somebody put
up on the internet, if you'd used the CLI to begin with, you merely pull it
from history, a few key strokes like this...
...incidentally the above starts
the Xine video player, with the sound fed
through a sox filter that is effectively an autolevel circuit with a built
in look ahead buffer so that the sound is acted on before it arrives.
No more straining to hear faint sounds, and then getting jarred out of your
seat on the loud ones, waking up everyone in the house that are trying to
sleep. Just try doing that with your mouse in the GUI.
10. Diverting system messages to VT23.
I would like to say don't do this one, because it doesn't even work,
unfortunately it does work, and everytime I boot up the machine that
has this gimmick, it reminds me that it does work, by beeping every little
bit, and I have to go in as root to turn off the stupid bell.
OK First of all it's experimental, but not in the sense that it will cause
problems, if anything it solves problems. The trouble is I was
never able to get it to solve the one problem I invented it for to
begin with, so I classify it as a failure, even though it clearly is not.
Also because I think of it as a failure, I never bothered to show
how to implement it on machines other than Debian Sarge, so if you have
some other machine, you'll have to skull out some of the missing details.
OK so are you OK with that? Good! Well here we go. This
one rates a Ten on the scripting complexity scale, compared to the
ease with which you've had these things go together up to now.
When you get this thing
completed, Syslog configuration will be
slightly modified to stop sending Emergency messages to the VT Console
and instead to send all messages, or part of them, or just Emergency messages,
take your pick, to a special VT Console tty23, and optionally ring
a unique sounding bell anytime a message comes in on tty23.
Why is this so important? OK let's say you're in an editor, banging
out something while someone else, lacking the latest advances, down the hall,
needed to load some programs from the latest DvD of Linux, and asked you to
mount up the DvD, so they could pull some files over an NFS connection.
That was yesterday, and you've forgotten all about it. But they haven't,
they've been busy getting configurations ready, and now you're editing
something, and the little red LED of the DvD drive, is furiously blinking
because a jelly donut deposit smeared on the disc is making it unreadable,
and your editing screen suddenly fills up with read error reports
from /dev/hdc pushing all your work off
the available screen space. Sound familiar? That was the scenario
this modification was suppose to fix, and it did'nt, apparently those errors
come from somewhere that Syslog wasn't looking for :-( Oh well.
However the scheme does work for the types of errors it does trap, and maybe
one fine day, I'll figure out where those errors are comming from and trap
them too.
Until then here's how to implement this mechanism:
OVERVIEW VT23 error diverter.
There are several pieces of this mechanism.
1. Two minor variants
of syslog.conf I call
them /etc/syslog_do-beep.conf and /etc/syslog_no-beep.conf
2. A pseudo device file, a pipe, in
the /dev tree masquerading as a device.
3. A Perl daemon /etc/init.d/beepmrgd to ring the bell once per line.
4. BASH startup script /etc/init.d/vt23beep
5. BASH startup script /etc/init.d/post_boot.sh
6. These
six
7. Just to
seven
8. Again if
eight
MINUTIA Obtaining the two syslog variants.
To describe to you precisely how to edit a copy of
the syslog.conf file
might work, maybe even most of the time you'll get through it error free,
assuming I didn't make any mistakes in the description of doing such
a mundane operation. But there is a better way. Actually if you
think about it, this kind of thing is required the world over, many times,
each and every day by programmers. Or if you prefer the term
coders. Most of what a programmer does, is not write whole
programs, no most of their time is spent debugging, that is rewriting
a very small, relatively speaking, portion of another existing program.
A pair of tools called diff and
a companion patch. Let's say I find
a better way to locate colors that human beings have trouble seeing, and
lets suppose I modify about 50 bytes scattered throughout a subroutine, and
it's supporting code. I suppose I could E-mail my altered
version of the color handler source code, and have others on my team
recompile the whole handler, but there's a much more efficient way to deal
with this. First I run diff against
the original version, and my edited version, of the subroutine, and it's
supporting code. This operation can, with the proper switches, build
a patch file of approximately 50 bytes,
actually there is some header, and tailer info, plus some syntactic sugar to
show what lines are stricken, added, and those to be left alone, in the
resulting file being built. If I E-mail this short
little patch file to my other team members
with instructions to run the patch program
on my patchfile once everyone gets used to
the idea, the world is a much better place. For one thing you can read
a patchfile before you apply it to the
code to be patched. As hard as that is to believe, the format of
a patchfile is comprehensible by us
human beings.
I felt it would be instructive to include my CLI commands I issued to
build the two patchfiles that you will
use to make the variant syslog configuration files, and due to
the cleverness of 50 million :-) opensource programmers all
getting a crack at diff and
the patch programs we all use, these
tools are so refined that they can often patch files from the future, that
were written yesterday! Just think what that means, I can patch
a program today, it can often be revised tomorrow, and my patch will still
work just fine. Such is the case for
the Do_beep and No_beep varients of
the syslog configuration, written for
Debian Sarge, yet can patch the radically
different rsyslog configuration files
For Debian Lenny as long as you drop
the "r" when you copy it to the work
directory.
The first resulting patchfile syslog_do-beep.conf.patch
--- syslog.conf 2010-01-10 15:39:00.000000000 -0700
+++ syslog_do-beep.conf 2010-01-10 15:45:20.000000000 -0700
@@ -45,7 +45,11 @@ news.notice -/var/log/news/news.notice
#
# Emergencies are sent to everybody logged in.
#
-*.emerg *
+
+# This is for the beepmrgd alternate system error message facility J.K.P.
+# *.* /dev/tty23
+*.* |/dev/bell23
+
#
# I like to have messages displayed on the console, but only on a virtual
The second resulting patchfile syslog_do-beep.conf.patch
--- syslog.conf 2010-01-10 15:39:00.000000000 -0700
+++ syslog_no-beep.conf 2010-01-10 15:46:08.000000000 -0700
@@ -45,7 +45,11 @@ news.notice -/var/log/news/news.notice
#
# Emergencies are sent to everybody logged in.
#
-*.emerg *
+
+# This is for the beepmrgd alternate system error message facility J.K.P.
+*.* /dev/tty23
+# *.* |/dev/bell23
+
#
# I like to have messages displayed on the console, but only on a virtual
First you'll need pseudo device file, a named pipe really, something
that you can feed data to, and have the outcome do something much like
a device file would do but, in this case, it not only diverts that data
to dev/tty23 but also rings a bell.
To accomplish this, do the following...
mkfifo /dev/bell23
Place the following listing in
the /etc/init.d/ directory in a file
called beepmrgd it is executed
by the program vt23beep shown below the
beepmrgd listing.
#!/usr/bin/perl
# /etc/init.d/beepmrgd
#
# This trivial program Copyright 2008, Jim Phillips may be copied only under
# the terms of either the Artistic License or the GNU General Public License,
# which may be found at www.fsf.org or if your machine is a Linux box, check
# in /usr/share/common-licenses for license listings.
#
# Although this program works as it is written, there are many short comings,
# lots of room for improvement, like maybe not sounding the bell on errors
# below a certain priority. Please feel free to modify it under the terms of
# the aforementioned licenses. See what I mean, I'll make a programmer of
# you yet.
use Proc::Daemon;
($source, $dest) = @ARGV;
if (($source eq "") || ($dest eq ""))
{
print "\nPurpose: To merge a beep into the outgoing data stream ";
print "anytime incoming pipe is fed a new line of data.\n";
print "Usage: beepmrgd named-instream tty-device\n\n";
print "A practical example might look like...\n\n";
print " /etc/init.d/beepmrgd /dev/bell23 /dev/tty23\n\n";
print "...Where /dev/bell23 is a named pipe, not a real device file\n\n";
exit;
}
# Test these files for openability, and then close them, while we
# can still die with a message that will print on our local terminal.
open (INFILE, "<$source") || die ("Can't open input file $source: $!");
open (OUTFILE, ">>$dest") || die ("Can't open output file $dest: $!");
# Note: the above 2 lines of code will hang until data is sent through it
# The proper proceedure for starting this Daemon is to first with
# syslog.conf set to NOT send anything to the bell pipe /dev/bell23
# and /etc/init.d/sysklogd restart run to "Make it so"
# You start the daemon by running /etc/init.d/post_boot.sh it has a
# line like /etc/init.d/beepmrgd /dev/bell23 /dev/tty23 that starts
# it. As noted above the code will hang until data is sent through it.
# Next edit /etc/syslog.conf to start sending messages to
# /dev/bell23 and run /etc/init.d/sysklogd restart to "Make it so"
# Since as sysklogd restarts it sends messages upon doing so, the bell
# will sound, a restart notification will appear on VT23, and the
# terminal that launched post_boot.sh is now reporting...
# "I/O selection found reasonable, and workable, beep going Daemon."
# and that terminal is now back at a bash prompt.
print "I/O selection found reasonable, and workable, beep going Daemon.\n";
close(INFILE);
close(OUTFILE);
Proc::Daemon::Init;
open (INFILE, "<$source"); # We've tested them, so open them blind
open (OUTFILE, ">>$dest");
while (1==1)
{
while ()
{
print OUTFILE "$_\007\r\n" ;
}
}
#!/bin/sh
#
# This vt23beep BASH script normally located at /etc/init.d/vt23beep
#
# start/stop Beep Merge Daemon beepmrg.d for VT23 message alert beeps
test -f /usr/bin/perl || exit 1
test -f /etc/init.d/beepmrgd || exit 1
case "$1" in
start)
echo "Starting VT23 Beep daemon:"
SYSLOGD="-f /etc/syslog_do-beep.conf"
pidfile=/var/run/syslogd.pid
binpath=/sbin/syslogd
echo -n "Restarting system log daemon: syslogd "
echo "using syslog_do-beep.conf"
start-stop-daemon --stop --quiet --exec $binpath --pidfile $pidfile
sleep 1
start-stop-daemon --start --quiet --exec $binpath -- $SYSLOGD
# - - -
echo
/etc/init.d/beepmrgd /dev/bell23 /dev/tty23
;;
# Of Course kill -9 `pidof -x /etc/init.d/beepmrgd` would be too simple
# Right? :-) I point it out for crude cmd-line control while debugging
stop)
echo "Stopping VT23 Beep daemon:"
bpmrgpid=`pidof -x /etc/init.d/beepmrgd`
if [ -n $bpmrgpid ]
then
{
kill -9 $bpmrgpid
# - - -
SYSLOGD="-f /etc/syslog_no-beep.conf"
pidfile=/var/run/syslogd.pid
binpath=/sbin/syslogd
echo -n "Restarting system log daemon: syslogd "
echo "using syslog_no-beep.conf"
start-stop-daemon --stop --quiet --exec $binpath --pidfile $pidfile
sleep 1
start-stop-daemon --start --quiet --exec $binpath -- $SYSLOGD
}
else
{
exit 1
}
fi
;;
*)
echo "Usage: /etc/init.d/vt23beep {start|stop}"
exit 1
;;
esac
exit 0
#! /bin/sh
#
# This file /etc/init.d/post_boot.sh is to make some finishing touches
# to the system.
#
# For this file to do anything at all, a symlink from /etc/rcS.d/ must
# point to it. Not only that, but the proper "Startup Sequence Priority"
# To layin a proper Startup Sequence for a Debian Sarge box execute the
# following link command:...
#
# ln -s /etc/init.d/post_boot.sh /etc/rcS.d/S55post_boot.sh
# You're wondering why, for instance, normally to change the number of loop
# devices you have to work with, it's a simple entry in /etc/modules.conf
# Debian went a little a-miss here, in Sid, and Sarge, for sure, maybe more.
#
# So I invented this file to fix things like this. Yes it's crude, like
# using a "goto" in 'C' but expedient. JKP
#
# -------------------------------------------------------------------------
# The rest of this post_boot.sh activates the alternate error message
# reporting daemon vt23beep that diverts these error messages to VT23
# -------------------------------------------------------------------------
# Set bell freq to 2Khz and dur 1/2 second on tty23 to make the sound unique
/usr/bin/setterm -bfreq 2000 -blength 500 > /dev/tty23
# Re-instantiate klogd to only bother console
# users with the highest priority messages
/bin/echo Re-Instantiating klogd at higher console message priority
if [ ! -z `/bin/pidof /sbin/klogd` ]
then
{
/bin/kill -HUP `/bin/pidof /sbin/klogd`
}
fi
/sbin/klogd -c 3
# Set VT23 to beep when a message from syslog is sent through the
# beep daemon /etc/init.d/beepmrgd /dev/bell23 /dev/tty23 on its
# way to VT23 the error message dumping ground.
/etc/init.d/vt23beep start
# Suggest things the Admin should do on this machine immediately after powerup
/bin/echo "Things one might want to do after powerup."
/bin/echo ""
/bin/echo "/etc/init.d/vt23beep stop Turn off VT23 audible message alert."
/bin/echo ""
11. Adding-or-Removing a bell tied to VT23 activity.
Here's where I left off Things_VT --L359--64% much more work needs to be
done on this file, as you can see
.----------------------------------------------------------------------------.
`----------------------------------------------------------------------------'
SVGATextMode+bell patch for 2.6.11-vz9.2
Subject: SVGATextMode+bell patch for 2.6.11-vz9.2
List-id: <linuxconsole-dev.lists.sourceforge.net>
James:
I noted that the SVGATextMode+bell patches where
absent from 2.6.11-vz9.2. I attach the diff.
I don't use framebuffers, SVGATextMode is faster and
looks better. The original patch was by Aivils. The
bell patch provides bells on vt's other than vt7, the
original is by Jean-Daniel Pauget.
Regards,
Hugo
Attachment: patch-2.6.11-vz9-92.hvw
Description: 2166988619-patch-2.6.11-vz9-92.hvw
Start X up on <Alt F8> ?
startx -- :1 -bpp 16
:1 == F8
:18 == F25
startx -- :18 -bpp 24
SYNOPSIS
chvt N
DESCRIPTION
The command chvt N makes /dev/ttyN the foreground terminal. The corre-
sponding screen is created if it did not exist yet. To get rid of
unused VTs, use deallocvt(1).
The keymap action `Console_N' (usually bound to key combination
(Ctrl-)LeftAlt-FN, with N in the range 1-12, and to RightAlt-FN-12 with
N in the range 13-24) also allows to switch to another VT, but really
switches only if it is already allocated. This prevents allocating new
VTs with a misplaced keystroke.
SEE ALSO
deallocvt(1).
CurDir = < /home/jim >
[jim@thinman]$ grep -i defaultserver /usr/bin/X11/startx
defaultserver=/usr/X11R6/bin/X
defaultserverargs=""
defaultserverargs=$userserverrc
defaultserverargs=$sysserverrc
server="$defaultserverargs"
server=$defaultserver
CurDir = < /home/jim >
[jim@thinman]$ # defaultserverargs="vt25"
CAPTION: Capacities of Compact Disc types
Type Sectors Data max size Audio max size Time
(MB) (MiB) (MB) (MiB) (min)
8 cm 94,500 193.536 ~= 184.6 222.264 ~= 212.0 21
283,500 580.608 ~= 553.7 666.792 ~= 635.9 63
650 MB 333,000 681.984 ~= 650.3 783.216 ~= 746.9 74
700 MB 360,000 737.280 ~= 703.1 846.720 ~= 807.4 80
800 MB 405,000 829.440 ~= 791.0 952.560 ~= 908.4 90
900 MB 445,500 912.384 ~= 870.1 1,047.816 ~= 999.3 99
Note: Megabyte (MB) and minute (min) values are exact.
CD capacities are always given in binary units, although decimal SI
prefixes are usually used: a "700 MB" CD has a nominal capacity of
about 700 MiB. DVD capacities, on the other hand, are given in decimal
units: a "4.7 GB" DVD has a nominal capacity of about 4.38 GiB.
