Late Linux

Sweet Recovery Mode and its Uses

2006-07-27T09:55:00.000+02:00

Hot water with sudoers
Got into hot water the other day, while modifying sudoers.

Thank God for IRC and the Ubuntu community. In a quarter of an hour, a very sweaty quarter of an hour, had the answer, and it worked a treat. If not mistaken, the user who gave me a concise, reliable piece of advice was rjib.

As all of this is new and odd, the lay of the land is not yet clear. Opened sudoers with visudo, as ought to. But default editor is nano. Think wanted a quick fix, to be able to open it with gedit. Or some other silly reason.

Ran chmod on etc/sudoers, the address of the sudoers file:

sudo chmod u+w /etc/sudoers

Don't recall if was pleased when ls -l showed that sudoers now indeed had a user write permission, but if any content there was, it was short-lived...

The catch of being locked out of sudo
The real result of the above clever tweak was being locked out of using sudo at all. Every time tried to use sudo, the system would tell me that the permissions on sudoers were wrong, and prompt me anew, without heeding my 'commands'. So, the system allowed me to paint myself into a corner...

Because, mind you, any imaginable way out involved being superuser. That includes, of course, changing to root:

sudo -i

...

Recovery Mode, the Knight in Shining Armor Gallops to the Rescue
rjib's advice was to restart in recovery mode.
In recovery mode, you're on the console, withtout a GUI...
But, you're root, the superuser...

Restarted, edited out the changes made to sudoers, and was good to go...

Obviously, with the power of being root in recovery mode, comes a power to harm. So, be forewarned...

Some Oddities of Shutdown

2006-07-27T08:38:00.000+02:00

Some conclusions from studies of shutting down in Linux (Ubuntu).This is the second of two posts.

Thanks to Cucisan and Metalheart for their help on the Ubuntu forums.

Some shutdown oddities
shutdown can be run in terminal or on a console, as any other command:
sudo shutdown -h now

Yet, in some ways, it seems to be unlike any other command.

The incompatibility with metacity oddity
For some reason unknown to me, it is impossible to include the shutdown command in the metacity user-defined keyboard shortcuts.
Thus, while
sudo shutdown -h now
works fine from terminal, it won't respond when included in a metacity shortcut (as explained in the post about shutdown keyboard shortcuts).

The CTRL-ALT-DEL oddity
In the default Dapper install, CTRL-ALT-DEL, a key combination used to reboot or shutdown, works only from the console, not from the GUI or even a terminal emulator.

Although it is commented out in /etc/inittab

# What to do when CTRL-ALT-DEL is pressed.
ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now

CTRL-ALT-DEL has no effect when used in the usual desktop environment.

man shutdown explains that CTRL-ALT-DEL is only recognized by the console [CTRL-ALT (F1 to F6) launch six independent consoles]. It is a unique key combination.
Even after removing the -a switch (see below) from the shutdown command in /etc/inittab (see above), CTRL-ALT-DEL is still recognized exclusively from the console.

The -a switch goes hand in hand with CTRL-ALT-DEL
Furthermore,
the -a switch, as in the command in the /etc/inittab file above, points to a file, /etc/shutdown.allow, which lists the users authorized to use the CTRL-ALT-DEL combination.
The -a switch is part and parcel of the CTRL-ALT-DEL key combination management- it only affects who can use this key combination. So the -a switch, too, is irrelevant on the desktop...

Indeed, upon creation of the /etc/shutdown.allow file with my username, as Metalheart suggested, could make CTRL-ALT-DEL work from the console, but still not from the terminal emulator.

Thus, in the terminal:
jackn@Phoenix:~$ sudo shutdown -a -r now
Password:
jackn@Phoenix:~$

a shutdown with the -a switch is ignored.

This, even though the /etc/shutdown.allow file is there:
#list of users allowed to use CTRL-ALT-DEL, a key combination that *only* works from the console.
jackn

The above results obtained after logging out and back in, for changes to take effect (prior to that, with the same files, the shell didn't even prompt for the password with the above command, but went right away to the next prompt).

Why and to be studied
As explained in man shutdown, the stringent management of CTRL-ALT-DEL must have to do with the days in which people worked on terminals hookd up to a central computer. Without such strictly regulated access, any user could have brought down the system from any terminal. I don't know if the keeping up of this setup serves any purpose today.

One issue remains to be studied, then:
What is it that doesn't allow the shutdown command, effective on the terminal, to work with metacity shortcuts like any other terminal command?

A Keyboard Shortcut for the 'shutdown' Command, and Modifying the sudoers File

2006-07-25T16:47:00.000+02:00

Some conclusions from studies of shutting down in Linux (Ubuntu).This is the second of two posts about shutdown.

Thanks to Cucisan and Metalheart for their help on the Ubuntu forums.

How to make a keyboard shortcut for shutdown
Love keyboard shortcuts.
By default, Dapper is shut down by clicking an icon on the desktop. So, a mouse is necessary. In addition, you go through an extra step, as a dialogue box pops up in response.

To get around that, can create a keyboard shortcut for the halt command, which shuts down the computer properly, namely, after closing the active apps (shutdown can't be used with metactity shortcuts).

As for the configuration of any other user-defined keyboard shortcut, launch the editor from the terminal (or with a keyboard shortcut...):
gconf-editor

In the GUI:
apps>metacity>keybinding_commands: gksudo halt
Then, in the global_keybindings tab : [favourite_shortcut]

As explained by Cucisan, gksudo is required by the graphic environment. It means the same as sudo in the terminal.
Mind you don't use something already taken by the system. CTRL-s, for example, is set to 'save as'...

Getting rid of the password popup (making 'shutdown' available to an ordinary user, not su)
To bypass the need to put in a password, followed the following instructions by Vivek.

The need to provide a password stems from the requirement to have superuser privileges in order to carry out some commands.
One of those commands is 'halt'.
Allowing use of such restricted commands by ordinary users requires modifying the sudoers file. This is a dangerous tweak. Was really careless in handling this myself, and spent a while with my heart in my mouth.

Warning: modifying sudoers is dangerous, should only be done when necessary and after proper study of the topic.

visudo
Only the visudo command allows access to the 'sudoers' file.
Study man visudo.
It will help to know what to do if you get into real trouble with visudo, as I have. Please see Sweet Recovery Mode and its Uses.

Before you start, you need to know the absolute path to your command. This can be obtained by:

which

To open 'sudoers' (/etc/sudoers):

$ sudo visudo.

Do not open the file directly, or do anything else directly with it.
It is to be edited only with visudo.

Inside sudoers
At the bottom of the file or at the 'user privilege spefication', append:

your_user_name ALL= NOPASSWD: /sbin/halt

It is desirable, as usual to preced this with some comment:

#Allwing ordinary users to use 'halt' without a password.

Now, save. You will be asked to confirm saving to /etc/sudoers.tmp, not /etc/sudoers.
You should say 'y'. The .tmp file is only a temporary version to allow one final hurdle before modifying 'sudoers' for good. The visudo command will now parse the changes for any syntax errors.

If there are any, visudo will issue an error message and ask 'what now?'.
To this, only two answers should really be considered: 'e' (back to editing) or 'x' (exit without saving the changes).

In my hands, the above (NOPASSWD) line only accepts one user and one command at a time. Proceeding otherwise will not be picked up by the visudo parser, yet will not dispense the user from the password prompt.

If all's well, you'll get the prompt again.

And, you'll be able to shut down the computer from the keyboard, without being prompted for a password.
Not bad.

.bashrc - Making Permanent Changes

2006-07-19T16:36:00.000+02:00

Some commands only affect the current session
Some commands only change the system temporarily, for the duration of the current session. Upon logging out, they are lost.

Two commands which behave in this fashion are export and alias.
Being unaware of this may lead the user to assume that previous safeguards are still in place, although in point of fact they won't be. Thought my change of rm (through alias; see post on 'alias'), to make it prompt me before removing, was hard-wired. As it wasn't, was less careful about removing than I could have been...
Not only safeguards are lost, of course. Also changes meant to tweak the system to the user's convenience are lost beyond the current session. How to set this straight?

Fix
In order to hard-wire any changes wrought by alias, export and others of their temporary ilk, it is necessary to put said commands in .bashrc.
.bashrc is a shell script in your home directory which is executed autmatically every time the shell starts (upon login).

First, open .bashrc:
jackn@Phoenix:~$ gedit .bashrc

In .bashrc, find the proper section. Use 'search' to find the 'alias' section, towards the end. The 'variable' section seems to be at the beginning.
Make the changes:

# Customized: An alias for rm to make it prompt the user for confirmation
alias rm='rm -i'

As in all shell scripts, the # in the first line means the following is a comment intended for the user, not a command to be run by the shell.
In the second line, the command figures exactly as it would in terminal.
It is easy to reset the shell to its default state before the changes. Just 'comment out' any changes in .bashrc by adding # at the beginning of the line. This leaves the change in the file, in case you want to apply it again, but the change is not applied by Bash:

# Customized: An alias for rm to make it prompt the user for confirmation
# alias rm='rm -i'

Generalizing changes to all the users?
The above changes will only apply to the user the .bashrc of whose home directory was changed. For changes to apply to other users, it is necessary to modify a system-wide file, or to leave each user to make changes in their .bashrc file, as they please. The system-wide file might be /etc/bash.bashrc, but haven't tested it yet.

The Lovely alias Command

2006-07-11T15:26:00.000+02:00

alias allows you to

a. Give a command a new name, or

b. Assign a command some desirable behavior by default.

The syntax is

alias new_name='old name'
or
alias command='command -switch'

In other words, the alias (the new name for a command or the name you wish to use for the new behavior of a command) always follows 'alias'. To the right of the equals sign, between single quotation marks, figure either the old name of the command or the new behavior assigned.

Warning: by default, alias is only valid for the current session. All changes will be lost upon logging out. To make aliases permanent, it is necessary to write them into .bashrc (see post).

The renaming can be handy if, for example, you'd like to give commands a name that you relate to more than the default name:

alias delete='rm'

will give the rm (remove) command a new name (alias), namely 'delete'.

As a result, it will be possible to carry out the operation of removing files with either delete or rm. alias, thus, gives the command an additional name - it does not replace the previous name.

The second way of using alias, to change the default mode of a command, can be handy if you wish a particular switch to be the default mode of a command (to save typing, or, more importantly, since you might forget to type it altogether): as a result of

alias rm='rm -i',

for example, doing rm will actually mean doing rm -i. This happens to be important, as the -i switch means that the machine will ask you whether you're sure that you want to remove the file concerned. Thanks to the alias, the machine will ask for confirmation even when you do rm absent-mindedly... Likewise, any command can be made to carry out by default any behaviour you happen to prefer.

Of course, the two uses of alias can be combined - the new default behavior can also be given a new name if you like:

alias delete='rm -i'.

(To be aware of: The system will allow you to assign a command a dedicated word already used as a command name. In that case, the dedicated word will denote the alias, not the command it usually denotes. Thus, as a result of

alias mv='ls'

mv will behave as an ls command, and not as the usual mv (move)... This behavior depends on the PATH variable, as fully stating the address of mv returns the usual mv behavior:

/bin/mv pilot pilot1

simply renames the file 'pilot'.
In short, it's best to avoid dedicated words already used by the system. When in doubt, a quick man or apropos on the new candidate name will tell if it's a dedicated word.)

To discard an alias, unalias will do:

unalias delete

means that 'delete' will no longer be a command.

To list all current aliases, just do 'alias'.

You can't do man alias, as alias, being a built-in shell command, is described in man bash. Further details and formal description of alias on: http://www.computerhope.com/unix/ualias.htm

alias is just one example, I guess, of what is meant by the power and flexibility of Linux.

Recovering xorg.conf

2006-07-04T22:15:00.001+02:00

xorg.conf
xorg.conf, usually in /etc/X11, is the configuration file for the X-windows system. The X-windows system runs the graphics card and serves, I think, as basis for the GUI (Graphic User Interface).

Disaster
Have lost it twice. Spent the whole day today recovering it for the second time. Had not managed to, would have had to reinstall Ubuntu - a time-consuming process entailing loss of settings.

Net Search Thanks to Dual Booting with Windows XP
So, to recover xorg.conf, had to manage by using Bash (the shell allowing access to the OS through command line only, not a GUI) commands. Used Firefox (dual boot system with Windows XP) to study solutions on the net. Some red herrings - Xfree68, for example, seems not to be relevant, a previous version of X.org.

Knight in Shining Armour - 'sudo dpkg-reconfigure xserver-xorg'
Finally, following net advice, did 'sudo dpkg-reconfigure xserver-xorg'. Put me through a whole series of questions, some quite technical and requiring a leap into the dark. When done, still no GUI...

Edit the xorg.conf File to Mint a New One
At this point, crucially, asking to edit the xorg.conf file was necessary. This worked on both occasions of loss of proper xorg.conf file, today and about two weeks ago. The system proposes a command to mint a new xorg.conf file: 'dpkg-reconfigure -phigh xserver-xorg'.
To enter editing mode, 'gedit' won't work, perhaps because it requires a window. Used 'nano', another text editor: 'sudo nano xorg.conf' (from inside the /etc/X11 directory).
Finally, though the file was properly rewritten, it was still necessary to relaunch the GUI (GDM? Gnome Desktop Manager? Or the X-Windows system - what is being relaunched?) by CTRL+ALT+BACKSPACE.

But then, happy end, the beatiful GUI was back there on the flat panel. Oof.

Intro to LateLinux

2006-07-04T21:49:00.000+02:00

Who and Why
Late bloomer, if you like. Mad about the web revolution. Chose Linux as my way to join the bandwagon.

Using Ubuntu Dapper, a Linux distro. Have been since perhaps June 2005. Would like to come to feel at home with it eventually. In particular, would like to understand system administration, rather than programming.

What
Will be regularly keeping record of trials, tribulations and insights as go along.