Startup ConfigsForum: DSL Tips and Tricks Topic: Startup Configs started by: mikshaw Posted by mikshaw on Aug. 03 2005,18:47
Anything put in this thread (by me anyway) will assume that you have an understanding of the backup/restore process. You may also find that some (or many) posts will not be kept updated anywhere near as well as the DSL distro itself. Some posts may in fact be useless by the time you read them =o)---------- Set up Multiple Virtual Terminals With Login Prompt files used in this lesson: /etc/inittab /etc/shadow /opt/bootlocal.sh /.bash_profile /home/dsl/.bash_profile The default behavior in DSL is to automatically log in user dsl in runlevel 5 and automatically start X. This is something I try to change immediately when setting up a new Linux system. In runlevel 2 you have multiple terminals, but all are already logged in as root. This is also something I care for not at all. The ideal situation, in my opinion, is what is found by default in many distros: When the boot process completes, you are presented with a login prompt. Press Alt+F# and you're taken to another virtual terminal with another login prompt. Here's what I did to get this in DSL... First thing, if you want a login prompt to work, the system will first need to know what password to accept. There are two ways I can think of to do this. One is to set up your passwords before doing anything else, and then backup /etc/shadow. The other is to boot with the "secure" boot option, setting up passwords when prompted each time you boot. The former will give you a quicker boot time, since the passwords will automatically be set up next time you boot. It also may be a bit more secure, as it can't be overridden by the "secure" boot option (unless the restore is disabled at the same time).../etc/shadow is restored *after* the passwords are set manually. /etc/inittab: change this
to this
The first one respawns only once in runlevel 5 and uses bash, which basically just opens a new shell for the same user (root). The second one adds runlevel 5 to the other lines, and uses getty, so you get a "real" virtual terminal set up to accept an interactive login. Since /etc/inittab is already read during the init process, before myDSL apps and backups are restored, The file will need to be read again before the user logs in. This can be done in /opt/bootlocal.sh:
This rereads the /etc/inittab file so your restored file will work. /home/dsl/.bash_profile automatically starts X when dsl logs in. You probably won't want this or you will have a new X session started on every terminal you login to (or you'll get errors...not sure which will happen). To fix this, remove the startx command from this file. You will then need to type "startx" in order to start an X session. /.bash_profile will automatically log in user dsl in runlevel 5 when you log in as root. You probably don't want that either. Remove the lines concerning "su dsl", or simply backup an empty version of this file. Now you should be presented with 4 virtual terminals when you start DSL. If you want more than 4, simply add more lines to /etc/inittab:
Posted by mikshaw on Aug. 04 2005,02:47
Just About Anything Can Be Triggered With A Boot OptionEverything you enter at the boot prompt or through the bootloader is stored in a file called /proc/cmdline. What this means for the user is that anything can be given at boot, regardless of whether it's built into DSL's boot scripts, and later be called up to trigger a command. This is very handy if you want something done during the boot process which isn't a standard part of DSL. A keyword can be entered at boot, and when /opt/bootlocal.sh runs just before login it could be scripted to search for that keyword, and react accordingly. Here's a simple example.... Say you want to automatically run syslogd, but not necessary every time you boot up. You could add the word "log" to your boot string, and then have /opt/bootlocal.sh check for that word:
The "chmod" command is optional...it just makes messages readable by regular users. There are a couple of ways to set up boot options, and the file /etc/init.d/dsl-functions provides easy access to these methods. You can check for a simple one-word boot option with the above egrep, or if you source dsl-functions in whatever script you use you can do it with "checkbootparam word", and you can check for a "word=something" with "getbootparam word" (getbootparam returns "something"). Posted by Deranged on Aug. 29 2005,18:05
Thanks. .bash_profile was what I was looking for, Now it logins how I want it. Thanks!
Posted by mikshaw on Sep. 19 2005,02:29
Pick One Of Several Window Managers To StartThere are several ways to specify which window manager to use when you start an X session. Here are a few methods: 1) Edit $HOME/.xinitrc every time before running startx (not an appealing method). 2) Write an xinitrc file for each window manager (.xinitrc.twm, .xinitrc.fluxbox, etc.) and symlink .xinitrc to the one you want to run at a given time. For example, if you want to start twm with this setup you could use something like this to start it:
3) Set up .xinitrc to start a window manager according to a parameter sent along with the startx command. This apparently doesn't work with DSL's startx, so i won't go into how to do this. 4) Set up .xinitrc to start a window manager according to an environment variable. You would need to export a variable ("wm", for example) with a keyword associated with a particular window manager, and then startx:
and .xinitrc would be set up to look for this variable before running the window manager. The following is from my current .xinitrc file, which works with the above command, and also works by using "wm=evil" in the bootloader's options.
EDIT: forgot to add the "CMDLINE" variable for getbootparam Posted by mikshaw on Sep. 19 2005,03:12
Use A Persitent Home And/Or Opt On The Same Partition As Root In FrugalThe current DSL init process fails to accept the 'home=' and 'opt=' boot options using the same partition as the KNOPPIX file system unless you use toram and frugal as well. Personally I prefer not to use toram, particularly when working with multimedia applications. So I've come up with a workaround. NOTE: This procedure runs from bootlocal, so it overwrites any home and opt files automatically restored from mydsl or backup.tar.gz. Do not use it if you autoload other files to home and opt. Step 1: Create /home/dsl and /opt directories on the partition containing KNOPPIX. These directories should not initially be empty, or you'll lose a lot of functionality. What I did was copy the directories from my DSL ramdisk. Step 2: Edit /opt/bootlocal.sh and back it up. You can back it up using the backup/restore process, or create a myDSL extension for this file. In addition to whatever other commands you want to run from bootlocal, you should also have the following:
What this will do is: a) Remove /ramdisk/home, /ramdisk/opt, and the symlinks to these directories. b) Create mountpoints for home and opt. c) Mount the new home and opt. If you want to do *only* home, it would look more like this:
This assumes that /cdrom is the location of the frugal install. I'm guessing that this is a standard location, but one should never assume =o) You probably should make sure of the location of KNOPPIX as seen from within DSL before doing this. Step 3: Reboot using the "frugal" boot option, and pointing either "mydsl=" or "restore=" to the location of your backup or mydsl extension containing the new bootlocal. The frugal boot option is vital, since you will need to be able to write to /cdrom. EDIT: If you are anything like me you probably do a lot of editing and re-editing of files, and if bootlocal.sh is one of these files you may find it annoying to have to create a backup or mydsl package every time you make a change to bootlocal.sh...particularly when you have a persistent opt that would normally make it very simple to make and keep changes. A way around this is to create a bootlocal.sh containing only the code above, followed by a command to run a second script (e.g. "exec /opt/bootlocal2.sh"). This way you can have all your other bootlocal stuff in an uncompressed, persistent script, making it easy to edit and forget it. Posted by doobit on Oct. 05 2005,18:38
Here's the official (I think it is anyway) Linux boot options link:< http://www.faqs.org/docs/Linux-HOWTO/BootPrompt-HOWTO.html > Posted by mikshaw on Oct. 25 2005,20:09
Automatically Set Up Xdefaults File According To A Specified ThemeI like using console applications, even in X, so at any given time I have at least two or three aterms open and have 3 different sets of aterm defaults for various console applications. This can be annoying when I decide i don't want to look at bright orange text on a particular day or if the current colors just look like poop with my current fluxbox theme...I have to go into .Xdefaults and manually change the foreground and cursor in all three. For a while I was using symlinks to multiple .Xdefaults files, changing the link when i wanted to change the color scheme. However, this means having to edit every Xdefaults file whenever i want to add or edit an application. So what I did was put the contents of .Xdefaults into .xinitrc, and have it automatically generated each time i start X. It looks in a file called .xtheme for the name of a theme, and writes $HOME/.Xdefaults according to what it finds. Now when i want to change the term colors I just do "echo [themename] > .xtheme" and then startx. The .Xdefaults file is built fresh and all of my terms are loaded with the appropriate color. If there is no .xtheme file it will use a grayscale theme. This is a simplified version of what I added to .xinitrc:
Don't use this exactly as is...it will overwrite your .Xdefaults file with its own. This can of course be expanded to make quick changes to other X applications and changes not relating just to colors, but this is just the main idea here. One feature i added as an afterthought (not sure how useful it is) is that it looks for the .xtheme file in the current directory, so you can have a different theme depending on where you are when you startx. Posted by mikshaw on Jan. 03 2006,21:35
GUI Desktop ChooserHere's a little flua script that will present you with a list of desktops from which to choose. It has fluxbox and jwm in it, but more can be added as a line-separated list called $HOME/.desktops.lst (the list overwrites the built-in list, so jwm and fluxbox need to be included in that file as well, at least for now). It works with the default .xinitrc in DSL2.1. To use it, add the path to the script to the top of .xinitrc, before the .desktop file is checked. IMPORTANT: 1) Do not add '&' after the command in .xinitrc because it won't work if you allow .xinitrc to continue while the script is loaded. 2) If you add any window managers to .desktops.lst, you will need to include them in the 'case' command in .xinitrc as well. 3) The script will currently run every time you start X, which means that if you switch from one desktop to another using the window manager's menu, you'll still get the GUI chooser. I just made this as a toy, to see if there is any interest in something more complex.
Posted by doobit on Jan. 03 2006,21:55
Mikshaw, it's a good idea! A lot of other distros have some kind of chooser on the login screen, which DSL does not have. Maybe you could put the security log-ins for root and dsluser on the same screen as the desktop chooser instead of having to enter it during boot?
Posted by mikshaw on Jan. 04 2006,02:31
That's a pretty good idea, but it wouldn't be very secure as part of this script. This script is not run during boot, and can be bypassed by pressing Esc. Since you're already logged in as dsl, and X has already been started, you are sent directly to the active desktop as usual.If you want a gui run during the boot process, the best you'll be able to do is have a whiptail script, run from /opt/bootlocal.sh or /cdrom/KNOPPIX/knoppix.sh unless you want to remaster the KNOPPIX file Posted by mikshaw on Jan. 20 2006,20:57
My .xinitrc I've been tweaking my .xinitrc file for months, and part of it was posted above. Now I've got it at a point where I think the main future changes will be just adding more content rather than features (but then, who knows...), and thought i'd post what it looks like at present. You SHOULD NOT just toss it into $HOME and expect anything from it...the result of this would likely be breakage of several applications' configurations, and many error messages. I'm just posting it here as an example of what CAN be done. If you were to use this script, you should read it and thoroughly understand what it's doing. I won't be held responsible for killing your system =o)
Posted by Zucca on Oct. 22 2006,20:39
I just had to add this topic to my bookmarks.
Posted by Zucca on Oct. 22 2006,20:49
mikshaw:You seem to use that case-statement sometimes... Like here:
I haven't used it but if I understand it is annother way to do if-statement where two values are compared and if it is true then perform commands. More simplier: if-statement with only '=' operator. And the other value never changes. Posted by mikshaw on Oct. 22 2006,21:40
I'm not sure how that would be simpler.The above code translated to "if" would be this:
From my point of view, it is redundant, larger, and more difficult to read, particularly if you end up needing nested "if" statements. It accomplishes the same task, but I tend to use "if" only for unique comparisons. If a single value is compared to several options, case is more appropriate in my opinion. BTW, I haven't used that script for quite a while. I still have it for those occasions where I want to quickly re-theme my X environment, but mostly I just use a simple script that starts root-tail and my window manager. Posted by Zucca on Oct. 23 2006,01:29
I got intrested when I just read somewhere that case supports wildcards too. =)
Posted by mikshaw on Oct. 23 2006,03:37
oh yeah...that's extremely handy.It also supports multiple results and case (as in upper or lowercase) variations, too. For example, you can use y|yes|YES) or [Yy][Es][Ss]) to test for variations on a "yes" response, where with "if" you'd need to make a long string to test for all of those variations. Posted by WDef on Nov. 02 2006,12:22
One thing that's nice about this type of thread is how different users get deep into their particular issues on dsl, then provide a resource for the rest of us by posting. If I feel the urge to fiddle with some of this stuff , Mikshaw's already done the work for us - all I have to do is find it on the forum.PS: I like case statements, too. I find them readable. Globbing in them can be handy also. For eg, Karl Knopper uses this type of thing a lot to test for a string within a string:
or something like that. This runs much faster than doing
which can be slow. Posted by Zucca on Nov. 02 2006,13:15
Good point. I need to make some changes to my scripts. ;)
Posted by WDef on Nov. 03 2006,17:00
I suppose you'd only need to change your scripts if they were noticeably slow - which greps can certainly do if you're grepping moderately biggish files etc.That famous C guy whats-is-name said "the best optimization is usually no optimization". He was referring to much optimization of code being insignificant on modern processors, therefore time wasting and bug prone, and that readability was more important. BTW I meant to say KLAUS Knopper - sorry Klaus baby! |