Beep Beep - pcspkr and snd_pcsp quiet please!

Having the flexibility to have the pc speaker / beep active in different contexts is useful, however it does require you to know, how to switch off beep, in each context.


tty terminal Ctrl+Alt+F1 - silence the beep:

Here (as root) I created a file named /etc/profile.d/beep-pcspkr-pcbeep-disable.sh and included a setterm command.

Permissions of 644 work okay for this file.

What you should now experience is a TTY console having no beep.

Switch to a tty console login using Ctrl+Alt+F1 and login, your shell completion should now be free of any audible feedback beep.


X terminal - xfce4 terminal - silence the beep:

Graphical desktops (X based) have their own preferences for audio feedback beep, and in my terminal xfce4-terminal, the preference is shown below:

MiscBell=FALSE

...which can be found in the file .config/Terminal/terminalrc

But my MiscBell=TRUE?

Change it to FALSE using an editor if you want to silence the beep.

But my user does not have a file .config/Terminal/terminalrc  - does not exist?

Xfce4-terminal has a preferences screen in Edit->Preferences, go into there and change 'initial title' from Terminal to Xfce4terminal and select 'Close'

What your action above did, was trigger the creation of .config/Terminal/terminalrc

Now you can make your edit.

Why would you want a beep anyway?

Some command line novices find the audible beep a useful feedback mechanism.

Being a novice, back before Red Hat became Red Hat Enterprise Linux, I remember using the feature myself.




But I still have a bootup and reboot Beep - absolute silence please?

Mute the 'PC Beep' column in alsamixer using the 'm' key.

• Startup alsamixer from a terminal (not required to be root)
• Navigate right until the PC beep column is highlighted
• Press 'm' to mute that column

Exit alsamixer using Esc (avoid pressing Q as this is the key for volume increase)

There is no need to explicitly save alsa settings, as simply exiting using Esc is enough to make your new settings persistent.

Note: PC Beep '00' is probably not going to be complete silence. Mute the thing.


Notes and Further Reading:

• Manpage of alsamixer  [ manpages.debian.net ]
• Screenshot of alsamixer [ screenshots.debian.net ]
• alsa-utils list of programs [ alsa-project.org ]
  
• Soundcard testing guide [ alsa-project.org ]
  

The alsa-utils package contains the program alsamixer. The package alsa-utils should already be installed on your system. If not use the following:

apt-get install alsa-utils

( apt-get above is for Debian and derivatives including Ubuntu)

yum install -y alsa-utils

( yum for Fedora / Red Hat / MeeGo and similar )

That alsa-utils package includes a utility named aplay, which can be used to check which sound devices in your system are known to alsa.

The above is a Dell Inspiron 1525 laptop, which I am currently setting up with Debian Squeeze. This laptop will have an Xfce desktop, and I have yet to test HDMI audio output, as HDMI port is not something I use regularly.

Terminal Preferences - #C0C0C0 and "Terminus Bold" 16

Terminal and "Grey on Black":

I am fascinated by folks who use white on black, and often wonder if it is just a lack of knowing, where / how to change the text colour.


#C0C0C0 is an nice Grey for text appearing on a Pure Black (#000000) background


Terminal Font - Monospace or Terminus:

The default in my Xfce terminal on Debian is 'Monospace', which is a perfectly usable font.

Going a little retro with Terminus

For widescreen desktop: "Terminus Bold" 16

For 15" laptop: "Terminus Bold" 14


Terminal Bell - love it or loath it:

For Xfce terminal, there is a MiscBell option in preferences file which should be set TRUE if you want to hear beep.

Terminal programs and terminal fonts - listings:

Just a quick hint or two for programs / fonts you might try.

Onboard Sata type - Ahci or IDE - which best

If you are a Windows user then you will have to go search based on your particular version - advice varies per version, and read up about install time drivers.

For GNU / Linux there is just a single set of current advice.
However if you are installing with a motherboard that has secure boot / Uefi, then you need to get familiar with these gatekeepers or experiment (some suggestions below )

This post has been edited since it was first published, and this 4 point summary is added:

1. Use Ahci rather than Ide mode where you are doing a new install
2. Existing installs should not switch from Ahci to Ide or vice versa once the operating system is already configured
3. The main thing that Ahci will give you is support for Native Command Queuing which is a hard drive feature.
4. If you are unable to install GNU/Linux with secure boot / uefi or other restrictive gatekeeper software with Ahci setting, then try ide mode and see if that allows the disk to be recognised (Later you can rebuild initrd and flick the bios switch if you feel you desperately need NCQ support)

If your problem is that the drive (hard drive / usb drive) is not being recognised so you cannot install Linux, then you can either become a master of secure boot zzzzzz, or just switch the thing off (there is usually a secure boot Yes/No in bios)


Choose at the outset - don't try changing it later:


The reasons for choosing Ahci or IDE will be covered next. But first you should make a commitment now to 'get it right' and stick with that setting.

To enable fast booting, grub (by default) will only includes the drivers it really needs, based on your initial system configuration.*

If you set your system up with 'Onboard Sata type' as Ahci, then later try and switch that mode in your bios, then you are asking for trouble.

If you set your system up with 'Onboard Sata type' as IDE, then later try and switch that mode in your bios, then you are asking for trouble.

Read on to make sure you 'get it right' at the outset.

*Sometimes this minimal approach is termed 'targeted' grub.


SATA and IDE emulation:

Do not use 'IDE mode' for Sata for any new install unless you are installing operating systems which had an initial release prior to 2007.

Use Ahci for current Debian and current Red Hat and similar.

The whole point of having a 'IDE mode' for SATA controllers was to help then current software ( Red Hat 5 & Windows XP ) cope with the change in disk standards.

The change to a newer version of Windows from Windows XP is not to be taken lightly for organisations with > 50 employees, which is why some IT departments continue to support that stable release.

Moving versions of Debian (Lenny -> Squeeze -> Wheezy) is much less of an issue, which is why most Debian installs were migrated from Etch long ago.

Moving point release of Red Hat Enterprise Linux (6.2 -> 6.3 -> 6.4) is also not a big deal, however there is just one caveat.

Red Hat is extremely popular as a base system for lots of virtualisation 'hosting containers'. If this is your situation, then that might require a little more planning  as hosting 40->200 VPS atop of Red Hat does make a migration a bit more involved.


Grub (initrd) and Ahci:

What will happen if you have 'Onboard Sata Type' set Ahci, and then do a GNU / Linux install, is that the boot mechanism (grub and initrd) will be built during install with --preload=ahci

To keep boot times down and loading from disk optimal, GNU / Linux installs keep the initrd minimal (only what your system needs*).

This approach gives sub 30 second boot times on my laptop (which I appreciate), however it does put the onus on you to choose the right bios setting and stick with it.

If 'Onboard Sata Type' was IDE mode when you installed, and then later you switched bios to be 'Onboard Sata Type' as Ahci, then ...

the workaround is to build a new initrd containing the AHCI module.

Source: Wikipedia

There is a great Fedora specific posting here describing in more detail why changing the bios setting after your install was done, will lead to issues.

*The latest Debian installer, specifically asks you if you want a 'targetted' boot setup or the more bloated but future proofed version - the choice is yours :)


Initially bios option was set 'Ahci' but for some reason now want IDE:

Hey maybe this is a little dose of nostalgia...what you are saying is in 2011 my system will be set to act like a 2006 / 2007 system.

Have no idea why you might choose to do this, however the kernel boot time option all_generic_ide might be what you require.


Ahci is not listed as an option in my bios - what should I do:

The bios menu selection might be titled 'Sata Controller Mode' or 'Onboard Sata Type' and should list two or three options.

Some bios have a selectable option named 'Compatible (sata only)', which is I guess just another way of saying Ahci



My operating system is very early version of Red Hat Enterprise Linux 5:

Check your kernel version. Kernel 2.6.18 is 5 years old now. Kernel 2.6.19 and newer, all support Ahci.

If you are thinking about doing an install today of a version of GNU / Linux that uses Kernel 2.6.18 then think again. Justify your choice to yourself.

The current 'stable' of Debian uses 2.6.32 and that is pretty conservative.

RHEL6 kernel is RHEL 6.0, Linux 2.6.32-71.29.1.el6.x86_64

Any kernel configured from the current kernel tree in the last 5 years,
should be > kernel 2.6.19 and therefore have Ahci support.

Kernel 2.6.32 and newer and Kernel 3.2 and newer have excellent support for Ahci.



There are other reasons why Kernel 2.6.18 for an OS acting as host container, might not be ideal.


Notes and further reading:

• Ahci operating system support [ wikipedia.org ]
• Kernel 2.6.18 is now considered 'legacy' [ linode.com ]
• Linux Kernel and signalfd support [ kvmdedicated.blogspot.com ]
• Kernel 2.6.18 released in 2006 [ kerneltrap.org ]
• Switching modes between Ahci and IDE - initrd implications
        [ fedoraforum.org ]
• Getting nostalgic with kernel option all_generic_ide
• Switching modes between Ahci and IDE - system woes [ techpowerup.com ]
• Supplying the correct driver to Windows XP and Ahci
       [ http://www.tomshardware.co.uk ]

If you are working with bios that make necessary choice between Ahci and IDE today, then perhaps rather than being nostalgic, you are installing GNU / Linux on second hand machines.

Plenty of non-profits and charities are using donated hardware, and this might be your work.

If so, you might also find this link regarding AC97 audio, handy for new installs of Debian Squeeze, on that legacy hardware.

For native English speakers a translation here

mercurial init - git init - summary clone and push

hg init            or      git init

...are generally the first commands I use.


Have your code ready and a reasonable directory structure in place.

Add a README and a LICENSE file (OSI approved licenses in my case)

hg init

...and you are up and running (for your git stuff   git init)

If you are working from an existing codebase then you might want 'clone'

hg clone http://hg.savannah.nongnu.org/hgweb/someproject

Publishing one time projects via git lends itself well to a set recipe:

1. git init
2. git add .
3. git commit -m 'first commit of GPL3 licensed python scripts'
4. git remote add origin git@github.com:someuser/apt-utils-python-shell.git
5. git push -u origin master
         [ Above we used -u switch (--set-upstream) which is correct ]
6. git add README
7. git commit -m 'added some to README'
8. git push origin master
         [ Note there is no -u switch here which is correct ]

Openshift and git - what commands there?

In order to commit to your new project, ...

Make your changes, then run:

git commit -a -m 'Some commit message'
git push

Then reload this page

Note: The above is quoted from the openshift page


Notes and further reading:

If you feel the desire to host your own Mercurial from which other folks can pull, then:

hg serve 

and the point browser at http://localhost:8000/


Note: If your machine is internet facing rather than on a private company network, then you should think about authentication / security, and follow this guide:
  Setting up a Mercurial CGI server

Alternatively you could think about Trac



If you feel the desire to host your own Git from which other folks can pull, then:

git-daemon 

and the point browser at http://localhost:9418/

Note: If your machine is internet facing rather than on a private company network, then you should think about authentication / security, and read up about gitosis or gitweb.

• Openshift repo at Red Hat
• Openshift tutorial videos [ openshift.redhat.com ]
• Openshift - sync local git repo with remote 'express' repo

mailserver A is "inherently" better than mailserver B

For GNU / Linux there are several good mailserver packages.

Here are a handful (in alphabetical order):

• Exim
• Postfix
• Qmail
• Sendmail

There are others, but for the purposes of this article that is enough to go on.

Each of these packages will have their own fanbase. If you have a long history with Plesk hosting automation, then you might well love Qmail ... why? Because you know it inside out.


Exim 4 is inherently more secure than Postfix:

No it is not.

Neither is Exim 4 inherently less secure than Postfix.

But there was recently a vulnerability in Exim 4 around dkim signatures?

Yes there was. Debian users should have the security repository of Debian active (by default) and automatic updates (usually active by default on login to Gnome).

( See links at the end for further information about Debian and automatic updates)

However postfix does get vulnerabilities also.

Mailservers are complicated and involve a huge codebase. Recent changes have been made, particularly to incorporate functionality around dkim.

When humans code, other humans will review and sometimes mistakes will be found and then corrected.


But what about Qmail - there is a stable codebase that has changed little in 10 years? Well Qmail has a small core codebase and recent functionality is added via patches. Is this a better way to maintain a mailserver? You decide.


Debian and Automatic Updates:

For Gnome desktop users (including Ubuntu migrants), the easiest way is to install update-manager-gnome

Here are some other useful packages if you run a different desktop, or prefer to have updates happen, without a graphical interaction:

• cron-apt which is a utility for background download (optional email output)
  
      [ once installed issue  ln -s /usr/sbin/cron-apt /etc/cron.daily/ ]
  
• aptdaemon another daemon, that can be used with user privileges and an optional frontend
  
  
• package named unattended-upgrades (see below)

If you are really comfortable with cron anyway, you might just want something like this for your updates:

50 11  * * * ( apt-get -q update && apt-get -qy upgrade -u )



The Debian project, and how an active upstream can influence choice:

Distributions are a little like biological systems in some ways, things become more popular, things become less popular. Not unlike natural selection in a fashion.

One of the things that Debian novices and even some experienced SysAdmins do not appreciate, is the importance of 'upstream'

It might be the tastiest code morsal your system has chewed in years, however somebody has to package the thing and maintain it
  
If upstream is inactive or uncooperative (it does happen), then it sometimes can put undue pressure on the maintainer.

With no upstream support, a complex package, will perhaps, have more outstanding bugs, or the maintainer might decide the weight it too much to carry alone.

Even if you are not doing Debian packaging, but might be making a commitment to a certain mailserver, then do ask about upstream.

How active is the upstream of Mailserver A?
How active is the upstream of Mailserver B?


If you are going to build a business around systems that include mailserver installs, then you want to know this!

Here is Exim own bug tracking system - how convenient :)


Crackers and mailservers - the case for mailserver diversity:

( Crackers: Folks who break into systems - think hackers if that is clearer for you )

If there was only one single GNU / Linux distribution, and every desktop and server in the world was GNU / Linux - wouldn't the world be great!

Well actually, NO.

Folks who make a business out of breaking into systems, have a skillset, just like regular developers and System Administrators.

The less the diversity in commonly run server based services, the better for the cracker.

In todays diverse GNU / Linux world that cracker is not going to just crack mailservers, he will likely have a toolkit of useful things s/he is knowledgeable in. SSL, file obfuscation, whatever.

However the wider the skill set required to be effective, the fewer people will be drawn into seeing 'blackhat' activities as an easy career.

Now if that cracker wants to compromise the mail server on a Red Hat system, then he needs to know Sendmail and it's vulnerabilities / attack vectors.

Now if that cracker wants to compromise the mail server on a Plesk automation system, then he needs to know Qmail and it's vulnerabilities / attack vectors.

Now if that cracker wants to compromise the mail server on a Debian system, then he needs to know Exim and it's vulnerabilities / attack vectors.

This is all assuming that the mailserver administrator has just 'gone with the flow'. They might not, they might have installed any of the 4 mailservers in my original list.

You know the Red Hat admin might have installed Exim, or the Debian admin might have installed Postfix.

My point is, that reducing diversity in mailservers, to the point that there is only one type of mailserver, might be considered making it easy for crackers.

Modern day cracking toolkits have lowered the barriers to entry for crackers somewhat. Let's not make it too easy for intruders by trying to extinguish choice through rabid fanboyism.

There are arguments for 'biodiversity' in the plant world. In this article, I have presented one argument for diversity in server based services.

I personally hope Qmail is around for another decade ... my argument for diversity.


Notes and Further reading:

An Extract from the Exim4 description:

If you build exim4 from the source package locally, you can also build an exim4-daemon-custom package tailored to your own feature set.

If your business is going to create some custom functionality around a mailserver, then that sort of thing might appeal.

• Number of installs of Exim 4 on Debian systems
• Number of installs of Postfix on Debian systems
• More about the Exim 4 dkim error including examination of the C code
• Exim dkim bug (bug #1106)
• Exim dkim Debian bug report #624670
• Debian Security page for Exim
• Postfix TLS and SASL related memory vulnerability May 2011
       CVE-2011-1720 and Debian package update

Here is an example of the type of debate that starts up when somebody asks "What mailserver for Debian".

( Nothing wrong with that sort of discussion, however do bear in mind my earlier point, about mailservers and fanbase. )