Archive for the ‘Linux’ Category

How-To fix the GPG error: “The following signatures couldn’t be verified because the public key is not available: NO_PUBKEY”

Wednesday, February 6th, 2013

These are the few command-line instruction to fix the GPG Error (NO_PUBKEY) that may appear when trying to run the ‘apt-get update’ command on a APT based system:

“GPG error: http://some.site.com stable Release: The following signatures couldn’t be verified because the public key is not available: NO_PUBKEY SOMEGPGKEY

This issue may reveal itself when you want to source packages from a repository that is unknown by your copy of the GPG  database, therefore APT will consider the repository as an untrusted source.

If you are sure that the repository is safe, you can circumvent the error manually adding the site’s public key to your GPG database using the following commands:

don’t use sudo if you act as root
$ gpg --keyserver subkeys.pgp.net --recv SOMEGPGKEY
$ gpg --export --armor SOMEGPGKEY | sudo apt-key add -

Comments and feedbacks and ‘like’ are welcome as always!

Download: (History of) Free Software Foundation In A Nutshell

Tuesday, October 9th, 2012

Here there are the PDF, MP3, M4B (audiobook) and iBooks versions of ‘Free Software Foundation In A Nutshell’

mp3: Free Software Foundation In A Nutshell

m4b: Free Software Foundation In A Nutshell

pdf: Free Software Foundation In A Nutshell

ibooks: Free Software Foundation In A Nutshell

Download and Share, please.

 

How-To Configure Wireless LAN on RaspberryPi With Raspbian Kernel 3.2.27+ And Solwise RTL8188CUS WiFi dongle

Friday, September 28th, 2012


RaspberryPi and Solwise WiFi dongle RTL8188CUS chipsetThe configuration of WLAN with a RTL8188CUS dongle on RaspberryPi is quite trivial now. It doesn’t’ rely on esoteric scripts, of manual installation of third-party kernel modules anymore.

I’ve been digging the solution for days before, it came alone at the beginning of September with a release of new ‘firmware’ for the RPi (see ‘A little of Story’ at the end of the post).

The procedure to install and configure a wireless network interface with Raspbian requires as little as a system upgrade and minimal understanding of the ‘wpa_supplicant’ utility.

Prerequisites

  1. The RaspberryPi must be powered with a 2A output USB charger because the WiFi dongle is very energy-thirsty, especially when it’s scanning the network for available SSIDs or when it’s creating the connection with the assigned SSID.
  2. The RaspberryPi must be installed with Raspbian version 2012-08-16-wheezy-raspbian or greater.
  3. The RaspberryPi must be connected to the internet via the ethernet card.
  4. It’s advisable to have the ‘avahi-daemon’ package installed (and running)
  5. The WiFi Dongle must not be plugged to the RaspberryPi until specified in the following procedure.
  6. It’s better to use a USB extension lead to connect the WiFi dongle to avoid the RaspberryPi to self-restart if the dongle is hot-plugged (or hot-unplugged).

Notes

I did notice that when the WiFi dongle is installed and active, sometimes it interferes with the usb keyboard (with both normal and wireless keyboards).

System Preparation

If your RPi is running a Raspbian version greater than 2012-08-16-wheezy-raspbian you can skip the System Preparation.

  1. launch a repository update:
    $ sudo apt-get update
  2. run a system upgrade:
    $ sudo apt-get upgrade
  3. make sure that the latest RaspberryPi firmware version is installed
    $ sudo apt-get install raspberrypi-bootloader
    The recent RPi firmwares include the Linux kernel version 3.2.27+ or greater.
    On Raspbian the RPi firmware is packaged as ‘raspberrypi-bootloader
     
  4. Install the wpa_supplicant utility:
    $ apt-get install wpasupplicant

WLAN configuration and wpa_supplicant set-up

We suppose that the WiFi dongle will be recognised as the wlan0 device.

Under some circumstances it may be recognised as wlan1 (..or wlan2 on so on), in such case modify the configuration accordingly.

Otherwise if you want your system to forcibly recognise the dongle as wlan0 you will have to play with the /etc/udev/ configuration files.

  1. Generate a PSK version of your WLAN password with wpa_passphrase utility
    $  wpa_passphrase My_WiFi_SSID mypassword

    the output will be similar to

    network={
        ssid="My_WiFi_SSID"
        #psk="mypassword"
        psk=b2abb0fcd2f4527e11817de0823a57bb19ba4622f4595062c94ec4dd1370b5fe
    }
    This output is meat to be an entry for a network configuration blocks of a wpa_supplicant.conf file.
    By the way we e will use it differently.

  2. Copy the ‘psk’ value of the wpa_passphrase output
    i.e. b2abb0fcd2f4527e11817de0823a57bb19ba4622f4595062c94ec4dd1370b5fe
  3. edit the /etc/network/interfacesand add the wlan0 configurations as follow:
    ...
    
    auto wlan0
    allow-hotplug wlan0
    iface wlan0 inet dhcp
      wpa-ssid "My_WiFi_SSID"
      wpa-psk b2abb0fcd2f4527e11817de0823a57bb19ba4622f4595062c94ec4dd1370b5fe
    alternatively you can use the clear-text version of the password
      wpa-psk "mypassword"
  4. Shutdown the RPi.
  5. Unplug the ethernet cable.
  6. Plug the WiFi dongle in the RPi’s USB port.
  7. Restart the RPi and wait that it connects to the Wireless LAN.

If the dongle will lighten up and you can ping or ssh into the Raspbian, congratulations, you’ve done it!

A little of story:

The Linux kernel 3.x comes with the module rtl8192cu.ko that is not able to properly recognised the WiFi dongle with the RTL8188CUS chipset, and when plugging the device, the RPi will hang on device detection of may even freeze.

The most recent versions on the RPi firmware (Sep 2012) have removed the buggy kernel module, and substituted it with a ‘manually’ compiled module called 8192cu.ko probably sources from the source code available at Realtek home page.

 

How-To Fix: “regenerate_ssh_host_keys …failed” on Raspbian for RaspberryPi

Tuesday, September 11th, 2012
Listen to me!
Audio MP3

download mp3
During your RPi boot it may happen that you get an error message like, “regenerate_ssh_host_keys …failed”, such error is generally sign that you SSH service won’t start.

That issue showed to me during the second boot of Raspbian on my new RsberryPi Revision B, due to the fact that during the previous session I did forcibly quit the raspi-config configuration tool exactly after issuing the command to enable the SSH server.

That caused the configuration process not to run the one-time operation of generating the ssh host keys necessary to run the sshd daemon. If fact, at the second reboot of Raspbian the script /etc/init.d/regenerate_ssh_host_keys (sim-linked by /etc/rc2.d/S01regenerate_ssh+host_keys), was  deleted as scheduled, but failed to start the SSH server because there were not the ssh keys supposed to be generated at the previous session.

The solution to the problem consists in manually generate the SSH keys and start the SSH server, executing the following commands:

~$ sudo ssh-keygen -t 'rsa' -f /etc/ssh/ssh_host_rsa_key
~$ sudo ssh-keygen -t 'dsa' -f /etc/ssh/ssh_host_dsa_key
~$ sudo ssh-keygen -t 'ecdsa' -f /etc/ssh/ssh_host_ecdsa_key

If requested for a password during the generation of these keys it’s advisable to leave it blank (empty) as they are ‘host’ keys and not personal keys.
Also confirm that you want to overwrite possible pre-existing keys that could be a partial leftover of the previously aborted generation process.

Please feel free to leave any comment and amend.

How-To Redirect PATHINFO (Almost Pretty) Permalinks To Pretty Permalinks

Wednesday, March 21st, 2012

This post is about supporting your former PATHINFO Permalinks structure (a.k.a. Almost-Pretty-Permalinks), on your new web-site using Pretty-Permalinks.

 Redirect 301 /index.php/ http://www.yoursite.com/
 RewriteRule . /index.php [L]

These are the lines of Apache’s configuration that must be present in the website’s main .htaccess file:

 <IfModule mod_rewrite.c>
 RewriteEngine On
 RewriteBase /
 Redirect 301 /index.php/ http://www.yoursite.com/
 RewriteCond %{REQUEST_FILENAME} !-f
 RewriteCond %{REQUEST_FILENAME} !-d
 RewriteRule . /index.php [L]
 </IfModule>

This case applies to those websites formerly configured to use PATHINFO Permalinks and for which all the old posts and pages have been indexed by the Web Search Engines (Google, Yahoo, Bing, etc) using the former structure that included the HORRIBLE! “/index.php” string in their URIs, i.e.:

https://www.marcomc.com/index.php/tech/

When these sites finally migrate to the Pretty-Permaling structure, the one that does NOT include the  horrifying “/index.php” piece, i.e.:

https://www.marcomc.com/tech/

it happens that all the search engines’ indexes will result suddently outdated, and that will penalise the sites at least in two ways:

  1. It will cause a loss of accesses because the back-links to the sites that are present on other blogs or in people’s favourites and bookmarks, or in the search engines’ indexes will be ‘broken’ (old) and the people will be unable to access the pages or posts unless browsing from the homepage.
  2. It will cause a loss of ranking in the search engines’ databases (S.E.O. perspective) because the sites will result ‘broken (unaccessible) and in some cases may even result like sites with duplicated content because the search engines’ spiders will index the pages as NEW pages (due to their new URIs) and the content will match the caches indexed with the old URIs (at least until the caches expire).

To prevent such mayhem you need to put in place a 301 (permanent) redirection that will tell the search engines that all the requests to URIs containing the ‘/index.php’ bit have to redirected to similar URIs not containing it, i.e.:

Redirect 301 /index.php/ https://www.marcomc.com/

This string gives instructions to the web server about what to communicate to the Search Engines when a PATHINFO request is received.

Most importantly the 301 redirection will instruct the search engines that the URIs containing “/index.php” have to be considered deprecated and that from now on, the site will not use it anymore. This is fundamental to avoid the search engines to consider the content of the site as a duplicated content.

Secondly you will need to put in place also a generic rewrite instruction that will tell the local web server (Apache) to accept all the incoming requests to URIs with a PATHINFO format and return the content of the new and purged URIs:

RewriteRule . /index.php [L]

This string gives instructions to the web server on what it must to do when a PATHINFO request is received.

I did use these redirection settings for my WordPress blog when I did migrate to a full L.A.M.P. server (GNU/Linux, Apache, MySQL, PHP) from the former Windows Server hosting service running Microsoft IIS and that did not support ‘.htaccess’ files but exclusively PATHINFO directives and for which I did not have access to the server’s core configurations, therefore I was forced to use “/index.php” in my permalinks.

If you did like this post leave a comment in sign of appreciation, ad if you are Facebook please consider to ‘Like’ MarcoMC.com page. Check the FB banner on the right widgets column of this page …     ========================================>>

I did take inspiration for this post at following this thread:

http://www.wptavern.com/forum/troubleshooting/489-mod_rewrite-make-pretty-permalinks-prettier.html

How-To Send A Command In Background And Keep It Running using ‘nohup’

Tuesday, March 20th, 2012

The shell command ‘nohup‘ in combination with ‘&‘ will allow to send the a command-line instruction in background enabling the process to keep running after the user who issues the command has logged out.

A common use of ‘nohup’ is when you need to issue a remote command via ssh connection and then you need to close the connection but be sure that the issued command will keep running in background, i.e.:

~$ sudo nohup shutdown -r -h 1203192100

I use this ‘trick’ when I want to restart my Mac and GNU/Linux Servers during evening/night hours but I want to submit the command during my office time.
In such way I save myself the time to remotely connect from home.

The ‘nohup’ command is even used to run processes in background as daemons.

nohup is a POSIX command to ignore the HUP (hangup) signal
(cit. from Wikipedia)


How the UNIX system Load Avarage is calculated on Mac OS X and Linux

Wednesday, August 24th, 2011

The Load Avarage values that are shown using the ‘top’ commad or the ‘uptime’ command represent the number of blocking processes in the run queue averaged over a certain time period.

An example fo HIGH Load Avarage:

 load average: 12.54, 12.71, 12.19

these values represent CPU, Disk I/O and Network I/O.

if you run the ‘top’ utility you can seek for the CPU usage and for the CPU I/O waiting time that are represented by the ‘us‘ and ‘wa‘ abbriaviations.

If these uage is permanently around 100% then chances are the problem is related to your CPU.

If the I/O waiting time is mostly above the 80% it means that there could be some problem with the I/O devices suche network cards or failing hard drives.

In my spefic case I notices that in ReadyNAS with 6 disks in RAIDX-2 the load avarage is constatly over 10.00,10.00,10.00. I believe this is normal considering that the ‘md’ process has to keep the RAID chain continuosly checksummed and alligned.

This information has been sources from Andy Millar’s really nice blog I have found digging around: http://www.andymillar.co.uk/blog/2006/12/24/linux-load-average-explained/

 

How-To user EtherApe graphical network monitor with Windows, Mac OS X or Linux

Monday, February 14th, 2011

EtherApe is a graphical network monitor for Unix that come with most of the GNU/Linux distrubution but is not, now is present in MacPorts for Mac OS X and but has no porting for Windows as well.

The best use of EtherApe is when it’s installed on a server (or any GNU/Linux machine) connected to the last-hop of your network to allow it to ‘sniff’ (analyze) the whole traffic getting in-and-out of your network. I suggest to put it on the  switch or hub that connects your network to the router.

Normally we monitor and manage our network from our workstation trying to access as less as possible the screen of our servers. Because EtherApe would be installed on one of our servers to visualize its output on our screen avoiding the user of screen remotization like VNC, TeamViewer or LogMeIn we need to use X11 protocol forwarding via SSH.

This solution implies that we have and X11 service running on our workstation.
If we are working on a Linux machine it can’t be more easy as we mostprobably are working on a X11 implementation.
If run Mac OS X then we ned to installe Apple’s X11, and you can find the installer inside the Installation disc.

For Windows the game is more tough because it’s not a Unix based system and a X11 server implementation is not part of the standard applications offered as part of the installation options.
Fortunately come in hand the project Xming a free implementation of X Server for Windows: http://www.straightrunning.com/XmingNotes/

The steps to visualize EtherApe on your workstation are:

  1. Install EtherApe on your GNU/Linux server:
    i.e. on a GNU/Debian server: 

    # apt-get install etherape
  2. Install X11 on your workstation:
    1. On Linux most probably you have installed x.org package
    2. On Mac OS X you install the package that you find in the installation disc
    3. for windows you need to donlaod the public release of Xming:
      http://sourceforge.net/project/downloading.php?group_id=156984&filename=Xming-6-9-0-31-setup.exe
  3. Install an SSH client on your workstation
    1. On Linux and Mac OS X it is part of the base system installtion
    2. On Windows you need to install PuTTY:
      http://the.earth.li/~sgtatham/putty/latest/x86/putty.exe
  4. Enable X11 forwarding through SSH on your server:
  5. Edit the file /etc/ssh/sshd_config and add or modify the X11 forwarding setting to
    X11Forwarding yes

    then restart the SSH service to load the new configuration

  6. On Windows only configure Xming to connect via the SSH client to your Linux server and specify to run the program xterm (or any other terminal application you have installed on your server) and specify as connecting user root or any sudoer user because EtherApe needs root privileges to turn the network card in listening mode.
  7. run EtherApe from the ssh connection just fireing the command ‘etherape’

Have fun!

How-To flush the DHCP server lease cache

Monday, January 17th, 2011

On a GNU/Linux server locate the files  dhcpd.leases and dhcpd.leases~
Mine is a Debian so the location is /var/lib/dhcpd3/ .

  1. delete the temporary file dhcpd.leases~:
    $ sudo rm dhcpd.leases~
  2. flush the lease cache dhcpd.leases:

    $ sudo echo "" > dhcpd.leases

the next time the clients will request a lease they will probably obtain a different IP respect the one they had before.