Blog

Installing a specific version of Bioconductor

2016-11-12T00:00:00+01:00

Bioconductor provide a list of R packages to analyse high-throughput genomic data. Every six months a new version of Bioconductor is released fixing the version of the included packages. It is always nice to come back to the same version of packages that generated the results.

Bioconductor versions are bound to R versions. So depending of the version of R you are using a limited number of Bioconductor versions are available. Using the default installation method of the Bioconductor the last version available for the R version is installed. We will see how to install a different version.

Install a specific version of Bioconductor

To install a specific version of Bioconductor, we need to use the installer of that version. To do so, we need to install the installer of the wondered version. The installer is in the BiocInstaller package we just need to use the correct repository to install it.

For example to install Bioconductor 3.1:

install.packages("BiocInstaller",
                 repos="http://bioconductor.org/packages/3.1/bioc")

Then load the BiocInstaller package as usual with library.

library("BiocInstaller")

Then install Bioconductor packages as usual with then biocLite() function.

Downgrade of already installed packages

In case you already install a more recent version of Bioconductor you can easily downgrade the packages to fit the Bioconductor version.

After loading the BiocInstaller you can have information about the Bioconductor installation with the biocValid().

For example

> biocValid()

* sessionInfo()

R version 3.2.4 Revised (2016-03-16 r70336)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Debian GNU/Linux 8 (jessie)

locale:
 [1] LC_CTYPE=fr_FR.UTF-8       LC_NUMERIC=C
 [3] LC_TIME=fr_FR.UTF-8        LC_COLLATE=fr_FR.UTF-8
 [5] LC_MONETARY=fr_FR.UTF-8    LC_MESSAGES=fr_FR.UTF-8
 [7] LC_PAPER=fr_FR.UTF-8       LC_NAME=C
 [9] LC_ADDRESS=C               LC_TELEPHONE=C
[11] LC_MEASUREMENT=fr_FR.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base

other attached packages:
[1] BiocInstaller_1.18.5

loaded via a namespace (and not attached):
[1] tools_3.2.4

* Packages too new for Bioconductor version '3.1'

                  Version  LibPath
annotate          "1.48.0" "/home/tblein/bin/R_3.2.4/lib/R/library"
AnnotationDbi     "1.32.3" "/home/tblein/bin/R_3.2.4/lib/R/library"
Biobase           "2.30.0" "/home/tblein/bin/R_3.2.4/lib/R/library"
BiocGenerics      "0.16.1" "/home/tblein/bin/R_3.2.4/lib/R/library"
BiocParallel      "1.4.3"  "/home/tblein/bin/R_3.2.4/lib/R/library"
Biostrings        "2.38.4" "/home/tblein/bin/R_3.2.4/lib/R/library"
DESeq2            "1.10.1" "/home/tblein/bin/R_3.2.4/lib/R/library"
genefilter        "1.52.1" "/home/tblein/bin/R_3.2.4/lib/R/library"
geneplotter       "1.48.0" "/home/tblein/bin/R_3.2.4/lib/R/library"
GenomeInfoDb      "1.6.3"  "/home/tblein/bin/R_3.2.4/lib/R/library"
GenomicAlignments "1.6.3"  "/home/tblein/bin/R_3.2.4/lib/R/library"
GenomicRanges     "1.22.4" "/home/tblein/bin/R_3.2.4/lib/R/library"
IRanges           "2.4.8"  "/home/tblein/bin/R_3.2.4/lib/R/library"
Rsamtools         "1.22.0" "/home/tblein/bin/R_3.2.4/lib/R/library"
rtracklayer       "1.30.4" "/home/tblein/bin/R_3.2.4/lib/R/library"
S4Vectors         "0.8.11" "/home/tblein/bin/R_3.2.4/lib/R/library"
XVector           "0.10.0" "/home/tblein/bin/R_3.2.4/lib/R/library"
zlibbioc          "1.16.0" "/home/tblein/bin/R_3.2.4/lib/R/library"

downgrade with biocLite(c("annotate", "AnnotationDbi", "Biobase", "BiocGenerics",
  "BiocParallel", "Biostrings", "DESeq2", "genefilter", "geneplotter",
  "GenomeInfoDb", "GenomicAlignments", "GenomicRanges", "IRanges", "Rsamtools",
  "rtracklayer", "S4Vectors", "XVector", "zlibbioc"))

Erreur : 18 package(s) too new

So as indicated by biocValid(), to downgrade all the package you just need to run the biocLite() function with the packages you would like to downgrade.

Sources

Automatic deployment of pelican website with GitLab - The local way

2016-08-27T00:00:00+02:00

We already saw a way to deploy our pelican website. To do it we add a SSH private SSH key to the environment variables. That not so nice since everybody that have access to the project can get the SSH private key. We will see here an other possibility to deploy our pelican website by mounting the final repository directly inside the build environment.

You will need to have functional installation of GitLab and GitLab Runner with Docker. In addition we suppose that the required python are in the requirements.txt file. The build and deployment will be managed with python and classical tools like mv, so a minimal docker image with python should be enough to do the job. The GitLab Runner should be on the machine that serve the website.

Create a runner

We will first create a runner that use docker that have python 2 installation and the web destination folder mounted (in our case it will be /var/www).

General runner registration

If not already done, you will need to setup a runner for the project:

# gitlab-runner register

Put the address of the coordinator. If GitLab is accessible trough http://gitlab.com, it should be something like http://gitlab.com/ci

Enter then the token that will link GitLab and the runner:

If you would like to have a shared runner go to the Admin Area, then Overview and finally Runners, to get the token.
If you prefer to have a runner for the project, go in the configuration menu of the projects and select Runners and use the token of the project.

Give a name to your runner and eventually some tags. I suggest to had as tags all the functionality of the runner. Indeed we can specify in the build system to use only the runners that carry specified tags. In our example the tags will be python2, www-mount

Specify the executor as docker and the docker image as python:2-alpine.

Configuration of the mounted volume

At the creation of the runner, automatically a volume is created as cache (/cache). We will add an other one that will be linked to a real path on the machine running the gitlab-ci-multi-runner.

To do it we need to edit the /etc/gitlab-runner/config.toml. Search the runner you are interested and change the volumes line as follow:

volumes = ["/cache", "/var/www:/var/www:rw"]

Each time the runner will be executed the /var/www folder of the host at the same place in the container as read write.

Deployment

Here are the different steps for the deployment.

Clone the repository.
First install dependencies with the help of pip and the requirements.txt file.
Generate pelican website.
Backup the old version of the website (just in case)
Move the output directory in the destination

Configuration of the continuous integration

We will create a Gitlab continuous integration configuration file (.gitlab-ci.yml) at the root of the repository. It is automatically recognised by GitLab. The file is inspired from the one proposed by GitLab.

image: python:2.7-alpine

pages:
  tags:
  - www-mount
  - python2
  script:
  - pip install -r requirements.txt
  - pelican -s publishconf.py
  - mv -f /var/www/website.domain /var/www/archives/website.domain.$(date "+%Y%m%d_%H%M%S") || true
  - mv output /var/www/website.domain

For the build we specify two tags here: www-mount and python2. This will allow the build system to select the runner that have the same tags.

Sources

PHP activation for nginx

2016-08-20T00:00:00+02:00

We will see how to let nginx execute PHP scripts and display their results instead of their content.

Configuration of PHP-FPM

Several possibility are available to execute PHP scripts Apache module, CGI, FastCGI and FPM. The later is an adaptation of the FastCGI version for heavy-loaded sites. It is the recommended installation to use with nginx.

We will start by installing the FPM version of PHP5

# apt install php5-fpm

nginx can discuss with the PHP-FPM process either through TCP socket or Unix socket. Since we will suppose nginx and PHP-FPM are on the same machine, we will use the Unix socket version.

First we check the configuration in the PHP-FPM configuration file (php5/fpm/pool.d/www.conf):

38 listen = /var/run/php5-fpm.sock

Then we restart the PHP-FPM service

# service php5-fpm restart

Configuration of nginx

We say to nginx where to find the PHP socket and to pass it the PHP files (extension .php). We need to put the following lines in the vhost files needing it. For the ease of the host configuration just put that lines in a new file called /etc/nginx/php.conf.

# pass the PHP scripts to PHP-FPM server listening on :code:`/var/run/php5-fpm.sock;`

location ~ \.php$ {
    include snippets/fastcgi-php.conf;

    # With php5-fpm:
    fastcgi_pass unix:/var/run/php5-fpm.sock;
}

You will just need to include that file in the virtual host that need to execute php scripts. For example for the default site (/etc/nginx/sites-available/default):

 1 server {
 2     listen 80 default_server;
 3     listen [::]:80 default_server;
 4 
 5     root /var/www/html;
 6 
 7     # Add index.php to the list if you are using PHP
 8     index index.html index.htm index.php;
 9 
10     server_name _;
11 
12     location / {
13         # First attempt to serve request as file, then
14         # as directory, then fall back to displaying a 404.
15         try_files $uri $uri/ =404;
16     }
17     include php.conf;
18 }

A restart of nginx is then necessary to take the new configuration into account:

# service nginx restart

Sources

Two factor authentication

2016-08-15T00:00:00+02:00

One time password are now spread in a lot of web services. They are valid only for a session and therefore even if intercept they can be used only once. Two methods are normalised by the Initiative For Open Authentication (OATH):

time based one-time password algorithm (TOTP) that is based on the combination of time and a shared secret to generate the unique password.
HMAC-based one-time password algorithm (HOTP) that is based on the combination of number of connection and a shared secret to generate the unique password.

To be able to use it, the user will need to have an application most of the time on her phone that generate the code asked by the server. The two algorithms are freely available as open standard and therefore numerous application are available to use them. The most known one is Google Authenticator That provide both a PAM module (for the setting on the server) and a phone application (for the user). However other phone application are available such as FreeOTP

Installation of the PAM module

Google developed a PAM module implementing the OATH-TOTP and OATH-HOTP. Its installation and configuration is simple. Since it is available in Debian repository to install it:

# apt install libpam-google-authenticator

After installation to use it on any PAM authentication module you need to a open the correct file and add the following line:

auth required pam_google_authenticator.so nullok

The nullok parameter allow the connection of the user without two factor authentication setup to connect normally.

Activation for `su`

Only need to madify the su PAM module in /etc/pam.d/su. Add the pam_google_authenticator line after pam_rootok.so

# This allows root to su without passwords (normal operation)
auth       sufficient pam_rootok.so
auth       required     pam_google_authenticator.so nullok

Activation for SSH server

First configure SSH PAM authentication module in /etc/pam.d/sshd. Had at the end of the file:

auth required pam_google_authenticator.so nullok

In /etc/ssh/sshd_config change the value of ChallengeResponseAuthentication from no to yes.

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication yes

By default the authentication will be managed as follow:

User that connect with a SSH key will log as usual
User that log with a password will in addition need to respond to a OTP challenge.

$ ssh user@server
Password:
Verification code:

Setting TOTP for an user

We will see here how to setup TOTP parameter for an user. It will be used by any PAM module where pam_google_authenticator is activated.

$ google-authenticator

Do you want authentication tokens to be time-based (y/n)

Answer yes to the first question to have time based on one time password (TOTP) or no to get HMAC-based one time password (HOTP). It will generate the shared code and display in your console a QR code ready to be scanned by your phone. If not displayed, you can open the link given to open the QR code. An example output:

https://www.google.com/chart?chs=200x200&chld=M|0&cht=qr&chl=otpauth://totp/user@server%3Fsecret%3DHENVXKRO4RFDSRDK

Your new secret key is: HENVXKRO4RFDSRDK
Your verification code is 580768
Your emergency scratch codes are:
28520578
41297079
99231833
99978459
29834705

In addition to the key it give you a verification code. This is the code generated at the time of QR code generation to be sure that is correctly entered. It give you also 5 emergency scratch codes that can be used at any time to login. They need of course to stored in a safe place.

Do you want me to update your "/home/user/.google_authenticator" file (y/n)

Answer yes to allow the module to setup the needed file for the authentication. Your secret key the different parameters and the emergency scratch codes will be saved in this file.

Do you want to disallow multiple uses of the same authentication
token? This restricts you to one login about every 30s, but it increases
your chances to notice or even prevent man-in-the-middle attacks (y/n)

Answer yes to allow only one utilisation of each password. It will block you to login twice in less than 30 seconds (default time resolution for password generation).

By default, tokens are good for 30 seconds and in order to compensate for
possible time-skew between the client and the server, we allow an extra
token before and after the current time. If you experience problems with poor
time synchronization, you can increase the window from its default
size of 1:30min to about 4min. Do you want to do so (y/n)

Answer no, the allowed timing of the password will be +/- 30 seconds. For most of the case it will be largely sufficient.

If the computer that you are logging into isn't hardened against brute-force
login attempts, you can enable rate-limiting for the authentication module.
By default, this limits attackers to no more than 3 login attempts every 30s.
Do you want to enable rate-limiting (y/n) y

Answer yes, it does not cost so much to strength the access even if the server already have some protection against brute force attack (like fail2ban).

Source

Nginx as a proxy

2016-08-13T00:00:00+02:00

We will see how to setup Nginx as a proxy to other web server. I used this configuration while transiting from lighttpd to Nginx. After installing Nginx I setup it to redirect all the web traffic to the lighttpd serrver. The aimed is to switch gradually from Nginx to lighttpd the different services served by lighttpd we as little interruption as possible.

Setup of the proxy for web traffic

An example of configuration file to transfer all request on port 80 to an other web server listening on port 8080.

 1 server {
 2     listen 80;
 3     listen [::]:80;
 4     location / {
 5         proxy_set_header X-Real-IP  $remote_addr;
 6         proxy_set_header X-Forwarded-For $remote_addr;
 7         proxy_set_header Host $host;
 8         proxy_pass
 9         http://127.0.0.1:8080/;
10     }
11 }

The proxy_set_header Host allow to tranfer address at which the proxy had been reach. Therefore, if the server listening on port 8080 as virtualhost they will work.

Setup of the proxy for encrypted web traffic

This is an enhancement of the previous one that redirect the traffic of port 443 to a https server listening on port 8081. In our case the TLS encrypted connection is setup on the proxy and the web server with letsencrypt and use the same certificates.

 1 server {
 2     listen 443;
 3     listen [::]:443;
 4     ssl on;
 5     ssl_protocols TLSv1.2;
 6     ssl_certificate /etc/letsencrypt/live/mydomain.tld/fullchain.pem;
 7     ssl_certificate_key /etc/letsencrypt/live/mydomain.tld/privkey.pem;
 8     ssl_dhparam /etc/ssl/certs/dhparam.pem;
 9     ssl_ecdh_curve secp384r1;
10     ssl_prefer_server_ciphers on;
11     ssl_ciphers EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH;
12     location / {
13         proxy_set_header X-Real-IP $remote_addr;
14         proxy_set_header X-Forwarded-For $remote_addr;
15         proxy_set_header Host $host;
16         proxy_set_header X-Forwarded-Proto $scheme;
17         add_header Front-End-Https on;
18         proxy_pass https://127.0.0.1:8081/;
19         proxy_redirect off;
20     }
21 }

Sources

Utilisation d'Nginx comme reverse proxy avec un certificat auto-signé, Let's Encrypt et un chiffrement fort

Automatic deployment of pelican website with GitLab

2016-08-03T00:00:00+02:00

Using static site generator like Pelican involved to rebuild it each time you modify it. Modern software forge like GitLab are able not only to manage code repositories but also make some continuous integration. Therefore they are able to run some command after each commit such as test, or build. In our case we will see how to rebuild and deploy our pelican website at each commit.

You will need to have functional installation of GitLab and GitLab Runner with Docker. In addition we suppose that the required python are in the requirements.txt file. The build and deployment will be managed with the make and therefore the Pelican generated Makefile should be correctly setup and notably the SCP parameters that will be used.

Create a runner

If not already done, you will need to setup a runner for the project:

# gitlab-runner register

Put the address of the coordinator. If GitLab is accessible trough http://gitlab.com, it should be something like http://gitlab.com/ci

Enter then the token that will link GitLab and the runner:

If you would like to have a shared runner go to the Admin Area, then Overview and finally Runners, to get the token.
If you prefer to have a runner for the project, go in the configuration menu of the projects and select Runners and use the token of the project.

Give a name to your runner and eventually some tags.

Specify the executor as docker and the docker image as python:2.7. This docker image not only include python but also some development tools such as GNU Make.

Deployment

Here are the different steps for the deployment.

Clone the repository.
First install dependencies with the help of pip and the requirements.txt file.
Setup a SSH configuration directory with correct POSIX right (~/.ssh)
Get the SSH public key of the server and had it to known_hosts with the ssh-keyscan command.
Create the required private key files (from SSH_PRIVATE_KEY environment variable). This will allow us to have it outside of the repository and therefore secret.
Generate pelican and upload to the ssh server with the help of make command.

Setup of the private SSH key

To avoid to have the private SSH key in the repository and therefore able to be read by everybody accessing it, we will save it in a GitLab Internal variable.

Put the content of the private key in a variable named SSH_PRIVATE_KEY. For this in the configuration menu of the project select Variables and create a new one with the name SSH_PRIVATE_KEY and put the content of id_rsa corresponding that is in between the -----BEGIN RSA PRIVATE KEY----- and -----END RSA PRIVATE KEY----- as a value. This variables will be specific to the project and available in the build environment. We will need to past this key in the correct file to be able to use it for SSH connection.

Configuration of the continuous integration

We will create a Gitlab continuous integration configuration file (.gitlab-ci.yml) at the root of the repository. It is automatically reconnised by GitLab. The file is inspired from the one proposed by GitLab.

image: python:2

pages:
  script:
  - pip install -r requirements.txt
  - mkdir -p ~/.ssh
  - chmod 700 ~/.ssh
  - ssh-keyscan -t rsa domaine.tld > ~/.ssh/known_hosts
  - echo "-----BEGIN RSA PRIVATE KEY-----" > ~/.ssh/id_rsa
  - echo "$SSH_PRIVATE_KEY" >> ~/.ssh/id_rsa
  - echo "-----END RSA PRIVATE KEY-----" >> ~/.ssh/id_rsa
  - chmod 600 ~/.ssh/id_rsa
  - make ssh_upload

Sources

pages / pelican

Gitlab-runner installation

2016-08-03T00:00:00+02:00

Installation of Docker

https://docs.docker.com/engine/installation/linux/debian/

Install gitlab-ci-multi-runner

https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/master/docs/install/linux-repository.md

Add gitlab-runner user to docker group:

# gpasswd -a gitlab-runner docker

Restart Docker service:

# service docker restart

Create a runner

# gitlab-runner register

Put the address of the coordinator. If Gitlab is accessible trough http://gitlab.com, it should be something like http://gitlab.com/ci

Enter then the token that will link Gitlab and the runner:

If you would like to have a shared runner go to the Admin Area, then Overview and finally Runners, to get the token.
If you prefer to have a runner for the project, go in the configuration menu of the projects and select Runners and use the token of the project.

Give a name to your runner and eventually some tags.

Specify the executor as docker and the docker image as python:2

Easy firewall with ferm

2016-07-27T00:00:00+02:00

It is a simplify interface to iptable, it allow therefore to configure the firewall with rules easier to read than iptable ones.

Installation

# apt install ferm

Configuration

The configuration takes place in the /etc/ferm/ferm.conf file. By default, only port 22 is open allowing SSH connexions:

proto tcp dport ssh ACCEPT;

To open port you only need to enter similar rules. Port can be specified by its number or by the name of the service that it is associated with it. To determined the name of the service associated with a port you just have to look inside the /etc/services file.

Sources

ferm - for Easy Rule Making

Executing a command at login

2016-07-26T00:00:00+02:00

Under Linux, the connexion is handle by the PAM (Pluggable Authentication Modules) authentication system. As is name said it, the functionality are spread in different modules like authentication backend (like LDAP, NSS) or action to do at connexion (like folder mounting).

pam_exec

The pam_exec module allows to execute an arbitrary command while connecting. Therefore it is possible to do what ever we want.

To activate it you only need to add the following line in your /etc/pam.d/common-session file:

[...]
session    optional     pam_exec.so    command
[...]

Replace command by the name of the command to execute.

Several environments variables are set so that can be used inside the program:

$PAM_TYPE
$PAM_USER
$PAM_RUSER
$PAM_RHOST
$PAM_SERVICE
$PAM_TTY

Email notification of a connexion

One of the classical function of this module is to send an email notification while a user is login. For this we will create the /usr/local/bin/send-mail-on-login.sh> script with the following functionality : - only work at the opening of new connexions - only for a limited number of user (for example admin and root) - send by email the connexion information to the administrator (admin)

#!/bin/sh
if ([ "$PAM_TYPE" != "open_session" ] ||
    ([ "$PAM_USER" != "root" ] &&
     [ "$PAM_USER" != "admin" ]))
then
    exit 0
else
    {
        echo "User: $PAM_USER"
        echo "Remote Host: $PAM_RHOST"
        echo "Service: $PAM_SERVICE"
        echo "TTY: $PAM_TTY"
        echo "Date: `date`"
        echo "Server: `uname -a`"
    } | mail -s "$PAM_SERVICE login on `hostname -s` for account $PAM_USER" root
fi
exit 0

Do not forget to let the script executable by running the following command:

# chmod + x /usr/local/bin/send-mail-on-login.sh

And to modify /etc/pam.d/common-session file accordingly:

[...]
session    optional     pam_exec.so    /usr/local/bin/send-mail-on-login.sh
[...]

Now at each connexion of root or admin, an email will be send to the administrator. For example after a ssh connexion of admin the administrator will receive a email like the following one:

User: admin
Remote Host: dslb-000-000-000-000.pools.arcor-ip.net
Service: sshd
TTY: ssh
Date: mercredi 22 juin 2011, 22:46:38 (UTC+0200)
Server: Linux test 2.6.32-5-amd64 #1 SMP Mon Mar 7 21:35:22 UTC 2011 x86_64 GNU/Linux

Source

Scripting avec pam_exec, notification de connexion

LDAP authentication for lighttpd

2016-07-26T00:00:00+02:00

Like a lot of web server, lighttpd can directly protect the access at certain pages or full folders by a password. This password protection is independent of web application that is protected like this. It's append before any access to the web pages and therefore of the application. The login/password couple can be set manually or looked inside a database. We will see here how to link with a LDAP database.

Configuration of LDAP authentication

To setup our configuration, we will modify (or create if absent) the file /etc/lighttpd/conf-available/05-auth.conf. First we need to configure the authentication mechanism. Here, it will be LDAP. All reference to other authentication mechanism such as plain should be removed:

server.modules                += ( "mod_auth" )

auth.backend                 = "ldap"
auth.backend.ldap.hostname   = "localhost"
auth.backend.ldap.base-dn    = "ou=People,dc=mydomain,dc=com"
auth.backend.ldap.filter     = "(uid=$)"

auth.backend.ldap.bind-dn  = "cn=user,dc=mydomain,dc=com"
auth.backend.ldap.bind-pw  = "secret"

auth.backend.ldap.hostname: server address
auth.backend.ldap.base-dn: tree were are the user saved
auth.backend.ldap.filter: filter to apply to obtain the users
auth.backend.ldap.bind-dn: login to use to bind to LDAP server
auth.backend.ldap.bind-pw: associated password

auth.backend.ldap.bind-dn and :code`auth.backend.ldap.bind-pw` parameters are only necessary if the LDAP server require a specific account to be able to access the different informations.

Configuration of folders to protect

Then we need to configure the folder that need to be protected by a password. For example tout protect the contain of the two folder /repertoire_securise and /autre_repertoire_securise:

auth.require =  ( "/repertoire_securise/" =>
                        (
                        "method" => "basic",
                        "realm" => "Password protected area 1",
                        "require" => "valid-user"
                        ),
                  "/autre_repertoire_securise/" =>
                        (
                        "method" => "basic",
                        "realm" => "Password protected area 2",
                        "require" => "user=admin1|user=admin2"
                        ),
                ),

Other folders could be added to the list likewise.

method: method type asked to the browser for authentication basic, plain, digest or htdigest. LDAP authentication in Debian only work with basic (various error for the others)
realm: Message to display in the connexion dialog box.
require: limitation to some user; a list of users separated by | or valid-user for any user of the database.

Configuration activation

Like all configuration of lighttpd, to activate it you need to create a symbolic link to the configuration file in /etc/lighttpd/conf-enable and to restart lighttpd:

# ln -s /etc/lighttpd/conf-available/05-auth.conf /etc/lighttpd/conf-enabled/
# /etc/init.d/lighttpd restart

Sources

Module mod_auth - Using Authentication

PHP activation for lighttpd

2016-07-26T00:00:00+02:00

We will see how to let lighttpd execute PHP scripts and display their results instead of their content.

FastCGI configuration of PHP5

To execute PHP scripts, lighttpd can use the standardised interface CGI that is used by web servers. It is an interface that allow easily the exchange between a web server and a rending engine. Two version of this interface are available in lighttpd, the classic one (CGI) and rapid one (FastCGI). We will use that latest in our configuration.

We will start by installing the CGI version of PHP5

# aptitude install php5-cgi

The configuration take place in the /etc/lighttpd/conf-available/10-fastcgi.conf file. It should look like the following:

server.modules += ( "mod_fastcgi" )
fastcgi.server = ( ".php" => ((
                     "bin-path" => "/usr/bin/php-cgi",
                     "socket" => "/tmp/php.socket"
                 )))

The first line activate FastCGI. The rest associates the file that have a .php extension to PHP and render them using the CGI version of PHP5.

Configuration activation

To activate the configuration you only need to create a symbolic link of that file in /etc/lighttpd/conf-enable folder:

# ln -s /etc/lighttpd/conf-available/10-fastcgi.conf /etc/lighttpd/conf-enabled/

A restart of lighttpd is then necessary to take the new configuration into account:

# service lighttpd restart

Authentification via LDAP pour lighttpd

2016-07-26T00:00:00+02:00

Comme n'importe quel serveur web il est possible, avec lighttpd, de protéger directement l'accès à certaines pages ou répertoires entier par un mot de passe. Cette protection par mot de passe est indépendante de l'application web sous-jacente. Elle s'effectue avant tout accès à la page et donc à l'application. L'association login/mot de passe peut être faite manuellement ou cherché dans une base de donnée. Nous allons voir ici comme faire cette recherche dans une base LDAP.

Configuration de l'authentification LDAP

Nous allons effectué notre configuration dans le fichier /etc/lighttpd/conf-available/05-auth.conf. Il faut d'abord configurer par quel mécanisme l'authentification va se faire. Dans le cas présenté ici, il s'agira de l'utilisation de LDAP. Toute référence à un autre système d'authentification comme plain doit être commenté:

server.modules                += ( "mod_auth" )

auth.backend                 = "ldap"
auth.backend.ldap.hostname   = "localhost"
auth.backend.ldap.base-dn    = "ou=People,dc=mydomain,dc=com"
auth.backend.ldap.filter     = "(uid=$)"

auth.backend.ldap.bind-dn  = "cn=user,dc=mydomain,dc=com"
auth.backend.ldap.bind-pw  = "secret"

auth.backend.ldap.hostname: adresse du serveur
auth.backend.ldap.base-dn: arbre où sont stockés les utilisateurs
auth.backend.ldap.filter: filtre à appliquer pour obtenir les utilisateurs
auth.backend.ldap.bind-dn: identifiant à utiliser pour se connecter au serveur LDAP
auth.backend.ldap.bind-pw: le mot de passe associé

Les paramètres auth.backend.ldap.bind-dn et :code`auth.backend.ldap.bind-pw` ne sont nécessaires que si le serveur LDAP requiert un compte pour pouvoir lire les différentes informations.

Configuration des répertoires à protéger

Il convient ensuite de configurer les répertoire qui doivent être sous le contrôle de mot de passe. Par exemple pour protéger le contenu de deux répertoires /repertoire_securise et /autre_repertoire_securise:

auth.require =  ( "/repertoire_securise/" =>
                        (
                        "method" => "basic",
                        "realm" => "Password protected area 1",
                        "require" => "valid-user"
                        ),
                  "/autre_repertoire_securise/" =>
                        (
                        "method" => "basic",
                        "realm" => "Password protected area 2",
                        "require" => "user=admin1|user=admin2"
                        ),
                ),

D'autre répertoire peuvent êtres ajouté à le liste de la même façon.

method: type de méthode demandé au navigateur pour l'authentification basic, plain, digest ou htdigest. L'authentification LDAP sous Debian ne marche qu'avec basic (erreur diverse pour les autres: non gestion pour plain et digest)
realm: message affiché dans la boite de dialogue de connection.
require: limitation sur les utilisateurs: une liste d'utilisateur séparés par | ou valid-user pour n'importe quel utilisateur de la base.

Activation de la configuration

Comme pour toutes les configurations de lighttpd, pour l'activer il convient de créer un lien vers le fichier de configuration dans le répertoire /etc/lighttpd/conf-enable et de redémarrer lighttpd:

# ln -s /etc/lighttpd/conf-available/05-auth.conf /etc/lighttpd/conf-enabled/
# /etc/init.d/lighttpd restart

Sources

Module mod_auth - Using Authentication

Activation de PHP pour lighttpd

2016-07-26T00:00:00+02:00

Nous allons voir comment faire pour que lighttpd exécute les scripts PHP et affiche leur résultat au lieu de leur contenu.

Configuration de PHP5 en FastCGI

Pour exécuter les scripts PHP, lighttpd peux utiliser l'interface standardisée CGI utilisée par les serveurs web. C'est une interface qui permet l'échange facile entre un serveur web et un moteur de rendu. Deux versions de cette interface sont disponibles avec lighttpd: la classique (CGI) et une version rapide (FastCGI). C'est cette dernière que nous allons utilisé.

On commence par installer la version CGI de PHP5.

# aptitude install php5-cgi

La configuration se situe dans le fichier /etc/lighttpd/conf-available/10-fastcgi.conf. Il doit ressembler à ceci :

server.modules += ( "mod_fastcgi" )
fastcgi.server = ( ".php" => ((
                     "bin-path" => "/usr/bin/php-cgi",
                     "socket" => "/tmp/php.socket"
                 )))

La première ligne active FastCGI. Le reste associe les fichiers avec l'extension .php à PHP et les exécute en utilisant la version CGI de PHP5.

Activation de la configuration

Pour l'activer il suffit de créer un lien de ce fichier dans le répertoire /etc/lighttpd/conf-enable:

# ln -s /etc/lighttpd/conf-available/10-fastcgi.conf /etc/lighttpd/conf-enabled/

Un redémarrage du serveur est ensuite nécessaire pour prendre en compte la nouvelle configuration:

# service lighttpd restart

tar and archives manipulation

2016-07-25T00:00:00+02:00

Archives and their manipulation

Archives files (.tar) allow to group together files and folder and their respective attributes in a single file.

You have to note that the options of tar utility can be passed without the habitual preceding dash -.

General options

The f option (like file) will be used to select the archive file to use for the operation. If not specified, the data are written directly on the STDOUT (creation) and read from STDIN (extraction).

During the creation and extraction of archives the v option (like verbose) allow the display of files that will be included/extracted by tar.

Creation

To create the archive, you need to use the c option (like create). Therefore to archive the test folder in test.tar:

$ tar cvf test.tar test

Extraction

The extraction itself use the x option (like in extract). Therefore to extract the test.tar archive :

$ tar xvf test.tar

Compressed archives

`gzip` compressed archives

The majority of archives are compressed and had the extension .tar.gz. They are archive files (.tar) that are then compressed by the gzip utility (.gz). Archive creation and extraction are done in two successive steps. To facilitate the use of compression, tar can directly use gzip with the z option.

To compress at creation our folder in a compress archive test.tar.gz:

$ tar czvf test.tar.gz test

And to uncompress it:

$ tar xzvf test.tar.gz

Other compressions

The archive files can be compressed by several compression algorithm. However, tar allow easily the use of some common algorithms by simply passing an option as for gzip:

bzip2, with j option (extension .bzip2)
lzma, with J option (extension .xz)
lzip, with --lzip option (extension .lzip)

Automatic detection of compression algorithm

To remember the different options for the different compression algorithms is not always easy. tar as a very nice option (a) that allows automatically to determine the right algorithm depending on the extension of the file.

Therefore to easily compress with gzip:

$ tar cavf test.tar.gz test

Or with bzip2:

$ tar cavf test.tar.bzip2 test

tar et la manipulation d'archives

2016-07-25T00:00:00+02:00

Les archives et leur manipulation

Les fichiers d'archives (.tar) permettent de regrouper un ensemble de fichiers et répertoire ainsi que leurs attributs dans un seul fichier.

Il est a noter que les options de l'utilitaire tar ne sont pas obligatoirement précédée du tiret - habituel.

Options communes

L'option f (comme file) quand a elle permet de spécifier le fichier de l'archive à lire ou à écrire. Si elle n'est pas spécifiée, les données sont écrites directement sur la STDOUT (création) et lues à partir de STDIN.

Lors de la création et de la extraction de l'archive l'option v (comme verbose) permet d'afficher les fichiers qui seront archivés ou extraits par tar.

Création

Dans le cas de la création c'est l'option c (comme create) qui est utilisée. Ainsi pour archiver le dossier test dans l'archive test.tar :

$ tar cvf test.tar test

Extraction

L'extraction quand à elle fait appel à l'option x (comme dans extract). Ainsi pour extraire l'archive test.tar :

$ tar xvf test.tar

Les archives compressées

Les archives compressées avec `gzip`

La majorité des archives est compressée et possèdent l'extension .tar.gz. Ce sont des fichiers d'archive (.tar) qui sont ensuite compressées par l'utilitaire gzip (extension .gz). La création et extraction d'archives se font donc en deux étapes. Pour faciliter l'utilisation de la compression, l'utilitaire tar peut appeler l'utilitaire gzip via l'option z.

Ainsi comme précédemment pour compressé notre dossier dans une archive compressée par gzip test.tar.gz:

$ tar czvf test.tar.gz test

Et pour la décompresser

$ tar xzvf test.tar.gz

Les autres compressions

Les fichiers d'archives peuvent être compressé par n'importe quel algorithme de compression. Cependant tar permet d'utiliser facilement quelques algorithme de compression par simple passage d'option comme pour gzip :

bzip2, avec l'option j (extension .bzip2)
lzma, avec l'option J (extension .xz)
lzip, avec l'option --lzip (extension .lzip)

Détection automatique de l'algorithme de compression

Se souvenir des différents codes pour les différents algorithmes de compression n'est pas toujours évident. tar fourni une option (a) qui permet automatiquement de déterminer le bon algorithme en fonction de l'extension du fichier.

Ainsi pour compresser facilement en gzip:

$ tar cavf test.tar.gz test

Ou en bzip2:

$ tar cavf test.tar.bzip2 test

Serving Mercurial repositories trough lighttpd

2016-07-23T00:00:00+02:00

We will describe here how to publish a group of Mercurial repositories on a web server. It will allow us to access it with a traditional web browser. For that we will link the web server to Mercurial with CGI. Once a repository is setup it is very easy to add others.

Pre-requirements

a functioning web server (here we will base on lighttpd for the instructions) see [[linux:debian:webserveur]] for its installation.
a classical installation of Mercurial.
The hgwebdir.cgi or hgwebdir.fcgi script include with your version of Mercurial. On a Debian install, you can find it in the /usr/share/doc/mercurial/examples/ folder. It is also directly available on Mercurial website: hgwebdir.cgi
In the case of use of the fastCGI version of the script (hgwebdir.fcgi) we should also install the flup python module (python-flup pour Debian)

Repository preparation

We will suppose that the repository is in the /var/hg folder. First we create the structure of the repository:

# mkdir -p /var/hg/repos
# chown -R www-data:www-data /var/hg

Then we create the configuration file of the repository /var/hg/hgweb.config which will allow us to take into account the different mercurial repositories that will be in the repos sub-folder:

[collections]
repos/ = repos/

Then we need to place the hgwebdir.fcgi script (in case of FastCGI use) or hgwebdir.cgi script (in case of CGI use) and to let executable by the web server:

# mkdir /var/hg
# cp hgwebdir.fcgi /var/hg
# chown -R www-data:www-data /var/hg
# chmod +x /var/hg/hgwebdir.fcgi

lighttpd configuration

In a sub-directory of the site

According to lighttpd documentation, we need to edit the /etc/lighttpd/lighttpd.conf configuration file or a file which will be include at lighttpd start up. In Debian you can create a file (for example 50-hg.conf) in the /etc/lighttpd/available-conf/ folder. Then create a symlink to that file in /etc/lighttpd/enable-conf/.

First you need to include the requiered modules:

1  server.modules += ( "mod_cgi" )
2  server.modules += ( "mod_rewrite" )

Second, you have to configure the address rewriting so the access to the sub-directories of hg should use hgwebdir.fcgi :

3  url.rewrite-once = (
4    "^/hg([/?].*)?$" => "/hgwebdir.fcgi$1",
5  )

Finally, passing the correct parameters to the CGI script:

6  $HTTP["url"] =~ "^/hgwebdir.fcgi([/?].*)?$" {
7               server.document-root = "/var/hg/"
8               cgi.assign = ( ".fcgi" => "/usr/bin/python" )
9  }

As a virtual host

In that case, the repositories will be accessible directly at the root of the host through an address like hg.example.com.

First, as before, you need to include the requiered modules:

1  server.modules += ( "mod_cgi" )
2  server.modules += ( "mod_rewrite" )

Second, in that case we will configure that all access to hg.example.com will use the FastCGI script.

3  $HTTP["host"] == "hg.example.com" {
4      server.document-root = "/var/hg/"
5      cgi.assign = ( ".fcgi" => "/usr/bin/python" )
6  }

In that case, the addresses will show the name of the cript to use, that is hgwebdir.fcgi. As before we could can use the rewriting directive to have sexier addresses, so without the name of the script:

7  url.rewrite-once = (
8      "^(/hgwebdir.fcgi/.*)$" => "$1", "^(/.*)$" => "/hgwebdir.fcgi$1"
9  )

In the Mercurial config file (hgweb.config) you should also specify that there is no prefix on the addresses:

[web]
baseurl =

Push limitation

The FastCGI/CGI script allow read but also write to the repositories. Therefore to be able to limit the write (push) to only certian person two additionnal modifications are requiered.

First in the configuration file of the mercurial repository itself where you want to put some limitation (.hg/hgrc). In the web section, add the names of the autorised users, or a star (*) to allow everybody:

[web]
allow_push = moimeme

Finally in lighttpd configuration in the file where authentication are specified:

$HTTP["querystring"] =~ "cmd=unbundle" {
                auth.require = (   "" => (
                        "method"  => "basic",
                        "realm"   => "Mercuial Repo",
                        "require" => "valid-user"
                        )
                )
        }

During a push it may failed with the following error:

ssl required

To allow pushes without SSL activated, just set it in the Mercurial configuration file of the corresponding repository (.hg/hgrc):

[web]
push_ssl = false

Sources

Publishing Repositories with hgwebdir.cgi

How to organise the source code of "templates"

2016-07-23T00:00:00+02:00

In C and C++, we normally separate the declaration and the definition of a function in two separated files: the header file contain the declaration of the function (.h or .hh file) and the source code itself which contain the definition of the function (.c or .cpp file). When we would like to do the same with function containing template we get an error of type undefined reference to when the function is first used in code.

An example

For example let's suppose that the addition function return the sum of two numbers of same type.

First the header file (addition.hh):

template<typename Type> Type addition(Type a, Type b);

Then the function source code (addition.cc):

template<typename Type> Type addition(Type a, Type b)
{
    return a + b;
}

Finally a small program using this function (main.cc):

#include "addition.hh"
void main()
{
    int a = 3;
    int b = 2;
    int c = 0;
    c = addition(a, b)
}

While the code looks correct, the links creation will broke with the following error:

/tmp/ccEpROXj.o(.text+0x17c): In function `main':
: undefined reference to `addition(int, int)'

Why?

There are different reasons that this error appear. It is mainly because a template is not a function but a model used to generate the function. When it used by a program to generate the real function, the definition should be known and not only it's declaration.

How to solved it.

There is several solution to that problem.

The insertion of the definition in the header file.

The first one is to include the definition in the header file. For that, we only need to fuse the two files (header and source code) in only one file or to include the source code file with an include preprocessing command at the end of the header file. This solution is the easiest one, but not the results is not so clean. Indeed, some compilers can increase dramatically the size of the resulting binary.

Adding a template specialisation

FIXME: To be confirmed

We can also add the declaration of the specialisation that we want in the source code of the function.

For example, for the previous addition function, we can specify the declaration for types int, float and double:

template<typename Type>
Type addition(Type a, Type b)
{
    return a + b;
}

template int addition<int>(int, int);
template float addition<float>(float, float);
template double addition<double>(double, double);

By using the `export` keyword.

FIXME

Sources

abort: requirement 'fncache' not supported!

2016-07-23T00:00:00+02:00

It can append that when we try to access a Mercurial repository we got the following error:

abort: requirement 'fncache' not supported!

It append when a "too old" version of Mercurial is used. Indeed, from version 1.1, Mercurial used a new repository format (fncache), which is no more readable by the former versions. The reverse is not true, and newer version are able to read old repositories.

To solve the problem we can use a version of Mercurial able to read the two type of repository and convert it to the old format using the following command:

hg --config format.usefncache=0 clone --pull A B

With A the initial repository and B the converted repository.

To completely deactivate the new repository format, a modification the configuration file of Mercurial is needed (~/.hgrc):

[format]
usefncache = False

Sources

fncacheRepoFormat

Unrealated repository fusion (mercurial abort: repository is unrelated)

2016-07-23T00:00:00+02:00

When we try to include a repository in an other while they never had any common point we got the following error:

$ hg push ../second
mercurial abort: repository is unrelated

To go above it we need to force the fusion with the -f option:

$ hg push -f ../second

Sources

hg man page

Deconnected subversion with SVK

2016-07-23T00:00:00+02:00

SVK installation

apt-get install svk

Create a local repository with the following command:

svk depotmap --init

Create a local repository mirror

svk mirror svn://adresse_du_depot_distant.ex //local/nom_local_du_depot
svk sync //local/nom_local_du_depot

Create a workingcopy from the local repository mirror:

svk checkout //local/nom_local_du_depot repertoire

Local use of SVK

Add some files/folders to version control

svk add fichier

Commit to the loacl repository mirror

svk commit

Push the modifications of the local mirror repository to the distant repository:

svk push

Sources

SVK par les Mongueurs de Perl

Syncthing on server

2016-08-20T21:15:00+02:00

Syncthing is peer to peer synchronisation software than run on a lot of platform. To be able to synchronise two devices they need to be both up at the same time. At the moment Syncthing is aimed to be run as a single user. Therefore if we want that several users are using it on the same machine several adjustement will be need.

Syncthing installation

The installation of Syncthing is well describe on their web site, and more particularly for Debian/Ubuntu with a dedicated repository http://apt.syncthing.net/.

Configuration for an user

First launch and connection to the interface

Setup a proxy to acces the web interface:

$ ssh -L 9090:127.0.0.1:8384 domaine.tld

Launch synthing

$ syncthing

Connect to the web interface http://localhost:9090

https://docs.syncthing.net/users/firewall.html#remote-web-gui

Configuration of Syncthing

Change default configuration to allow multiple run of Syncthing (one per user). The main parameters to change are the port that the instance of Syncthing will use for first its web interface and second its connection.

Device Name: to have a idea of server and user
Sync Protocol Listen Addresses: tcp://:22001 (by default tcp://:22000)
GUI Listen Addresses: 127.0.0.1:22002 (by default 127.0.0.1:8384)

If on a server with direct connection to Internet deactivate "Enable NAT traversal" and "Enable Relaying".

After restart you need to restart the ssh proxy with the new GUI Listen port:

$ ssh -L 9090:127.0.0.1:22002 domain.tld

Firewall

You will need to open the firewall to allow entry of the synchronisation so open TCP port corresponding to "Sync Protocol Listen Addresses". If you want a direct access to the web interface without the SSH proxy you could open also the corresponding port.

User setup for automatic start

With the help of systemd

If it does not exist create the systemd user directory:

$ mkdir -p ~/.config/systemd/user/

Create a Syncthing service file to setup the service from the example on the Syncthing github:

$ wget -O ~/.config/systemd/user/syncthing.service \
    https://github.com/syncthing/syncthing/raw/master/etc/linux-systemd/user/syncthing.service

It should contain something like the following:

[Unit]
Description=Syncthing - Open Source Continuous File Synchronization
Documentation=man:syncthing(1)
After=network.target
Wants=syncthing-inotify.service

[Service]
ExecStart=/usr/bin/syncthing -no-browser -no-restart -logflags=0
Restart=on-failure
SuccessExitStatus=3 4
RestartForceExitStatus=3 4

[Install]
WantedBy=default.target

Activate the script:

$ systemctl --user enable syncthing.service

Now you can start and stop Syncthing using systemd tools. Start Syncthing:

$ systemctl --user start syncthing.service

To allow the start without any connexion of the user as root:

# loginctl enable-linger USER

We then create a crontab entry to start Syncthing at reboot of the computer (crontab -e):

@reboot systemctl --user is-active syncthing.service &>/dev/null || systemctl --user start syncthing.service &> /dev/null

We first test that the service is not running before starting it. We can also test regurlaly that the service is running and if not start it:

To do it every hours:

0   *   *   *   * systemctl --user is-active syncthing.service &>/dev/null || systemctl --user start syncthing.service &> /dev/null

Sources

Offline and caching of LDAP authentication

2014-08-22T00:00:08+02:00

Centralised authentication through LDAP is very useful. No matter the number of machine that used it, the user have the same login and groups. When the user change his password on one of the machine, the password is updated everywhere. However in case of lack of connection with the LDAP server it is no more possible to login. Here we will see how to configure sssd to provide caching and offline support of identity and authentication to the system.

You will need to have a working LDAP server that is able to provide authentication. On the client first install sssd package:

# apt-get install sssd

It should also install libpam-sss and libnss-sss packages that provide the binding for authentication and identity. Be sure to remove any other caching server like nscd.

All the configuration is done in the /etc/sssd/sssd.conf file.

[sssd]
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
debug_level = 10

services = nss, pam
domains = EXAMPLE

[nss]
filter_groups = root
filter_users = root
reconnection_retries = 3

[pam]
reconnection_retries = 3

[domain/EXAMPLE]
enumerate = false
cache_credentials = true

id_provider = ldap
auth_provider = ldap
chpass_provider = ldap

auth_provider = ldap
ldap_uri = ldap://ldap.example.com/
ldap_search_base = dc=example,dc=com
ldap_tls_reqcert = never
ldap_tls_cacert = /etc/ssl/certs/ca-certificates.crt
ldap_default_bind_dn = cn=admin,dc=example,dc=com
ldap_default_authtok_type = password
ldap_default_authtok = xxxxxxxxx

Sources

Delete duplicate messages in Mutt

2014-01-29T13:13:59+01:00

Duplicated message in a mail box could append when consolidating to mailbox or only by mistake. Since each message is identified by an unique message-id while sending, duplicated message have the same message-id, and therefore can be easily identified.

To identify them with mutt, you need to configure it to thread duplicated messages together when sorting by threads. This is done through the duplicate_threads configuration variable. If active, the duplicated messages will be marked with an = in the thread diagram.

To activate it, put in your .muttrc the following line:

set duplicate_threads = yes

or type in mutt :set duplicate_threads = yes. To check if it is active, type in mutt :set ?duplicate_threads.

Know to identify the duplicated messages you can use the ~= pattern and use it for marking or deleting them.

For example to tag all the duplicated messages type T for tagging according to a pattern and then ~= to select the duplicated messages in the folder. If you want to delete them use D for deleting according to a pattern and then ~= to select the duplicated messages in the folder.

Sources

Xerox Phaser 6010N on Debian 64bits, the multiarch way

2013-03-03T20:34:06+01:00

Xerox gives the drivers only for 32bits Linux boxes. We already saw how install it with the help of the 32bits libraries (Xerox Phaser 6010N on Debian 64bits). However this method is now depreciate in favour of the multiarch possibility.

AMD64 processor are able to run any 32 bits programs. That why the installation of a 32 bits OS is possible on that architecture (i386). Recently Debian provide the possibility to had additional architecture to the OS. I the case of amd6' architecture it will allow the installation of i386 packages on the system.

By default, a 64 bits package will be installed. They are uncompress in specific folder link to he architecture. Links to the classical emplacements. In adding the i386 architecture, we will create an other emplacement to put the corresponding package. This will allow us to run i386 software and libraries on the amd64.

Adding i386 architecture

Add the i386 architecture:

# dpkg --add-architecture i386

Update the package to take into account the i386 ones:

# apt-get update

Installation of the Xerox drivers

Go to Xerox web site to download the Phaser 6010 deb package on the Linux page. Select English as language since the complete drivers are only available in English.

To install it:

# dpkg -i xerox-phaser-6000-6010_1.0-1_i386.deb

Note that you do not need to force the architecture since to i386.

The installation will complain about an unmet dependency:

Sélection du paquet xerox-phaser-6000-6010 précédemment désélectionné.
(Lecture de la base de données... 298522 fichiers et répertoires déjà installés.)
Dépaquetage de xerox-phaser-6000-6010 (à partir de .../xerox-phaser-6000-6010_1.0-1_i386.deb) ...
dpkg: des problèmes de dépendances empêchent la configuration de xerox-phaser-6000-6010 :
xerox-phaser-6000-6010 dépend de libcups2 (>= 1.2.7) | libcupsys2 (>= 1.2.7) | libcupsys2-gnutls10 (>= 1.1.23-1) ; cependant :
Le paquet libcups2:i386 n'est pas installé.

dpkg: erreur de traitement de xerox-phaser-6000-6010 (--install) :
problèmes de dépendances - laissé non configuré
Des erreurs ont été rencontrées pendant l'exécution :
xerox-phaser-6000-6010

To solve it, we just need to install it:

# apt-get install libcups2:i386

Configure the printer

Install and configure the printer with the proposed Xerox driver.

In cups configure it as an AppSocket/HP JetDirect printer. Enter the IP of your printer and use the port 9100 as follow: socket://192.168.1.1:9100. Give a name, a description and location to the printer In the driver selection select Xerox as manufacturer and Xerox Phaser 6010N as model.

Sources

Multiarch HOWTO on Debian wiki

OpenVPN server on OpenWRT box

2013-03-03T19:07:52+01:00

While you are away from home it is sometime needed to access some files on the home file server. To protect it it is not directly available from the web. We will see here how to create a secure connexion to connect from the web on your OpenWRT box to be able be like at home.

Installation of OpenVPN

For this we will install an OpenVPN server that will allow us to create a Virtual Private Network. Just install the openvpn package with the web interface or the help of opkg on command line.

To work, OpenVPN need several keys and certificates. To handle it, OpenVPN community provide a set of script to easily create all what is needed. It is called easy-rsa. You can install the openvpn-easy-rsa package on your OpenWRT box or download easy-rsa from the web on your unix computer to save place on OpenWRT.

Keys and certificates creation

Go inside the easy-rsa folder (/etc/easy-rsa/ on OpenWRT). First edit vars file inside easy-rsa to fit your requirements:

export KEY_COUNTRY="FR"
export KEY_PROVINCE="FR"
export KEY_CITY="Paris"
export KEY_ORG="At Home"

Then creates the keys that are needed to signed all the key and certificates generated:

./clean-all
./build-ca
./build-dh

Create the server key and certificate:

./build-key-server my_server_name

Copy on the OpenVPN folder of the OpenWRT box the server files that where generated in the keys folder:

cp ca.crt ca.key dh1024.pem my_servername_.crt my_server_name.key /etc/openvpn/

ca.crt is the Certificate Authority (CA) certificate. The corresponding key is used to sign all the certificates and keys and it all to check the validity of provided certificate.
dh1024.pem contains the Diffie-Hellman parameters for the server side of an SSL/TLS connection.
my_server_name.key is the key used by the server to decrypt the messages from the client.
my_server_name.crt is the certificate that the server provide to the client to allow it to crypt the conection. It is signed by the CA to prove that it is coming from the server.

Then for each user create the corresponding key and certificate:

./build-key user1
./build-key user2

Give to each user the generated files: ca.crt, user_name.key user.name.crt. They are the only needed files for them

Open the correct port in your firewall

You must open the 1194 port in the firewall to all the OpenVPN connection from the WAN. You can do it through the web interface or by editing the /etc/config/firewall file:

config 'rule'
        option 'target' 'ACCEPT'
        option 'dest_port' '1194'
        option 'src' 'wan'
        option 'proto' 'tcpudp'
        option 'family' 'ipv4'

Do not forget to reload the firewall rules if you modify it on command line:

/etc/init.d/firewall restart

Server configuration

The configuration of OpenVPN is set in /etc/config/openvpn file:

config 'openvpn' 'lan'
        option 'enable' '1'
        option 'port' '1194'
        option 'proto' 'udp'
        option 'dev' 'tap0'
        option 'ca' '/etc/openvpn/ca.crt'
        option 'cert' '/etc/openvpn/server.crt'
        option 'key' '/etc/openvpn/server.key'
        option 'dh' '/etc/openvpn/dh1024.pem'
        option 'ifconfig_pool_persist' '/tmp/ipp.txt'
        option 'keepalive' '10 120'
        option 'comp_lzo' '1'
        option 'persist_key' '1'
        option 'persist_tun' '1'
        option 'status' '/tmp/openvpn-status.log'
        option 'verb' '3'
        option 'server_bridge' '192.168.1.1 255.255.255.0 192.168.1.200 192.168.1.219'

This configuration will allow the client to be part of the network handled by the OpenWRT box. It will grab a IP i the range 192.168.1.200 to 192.168.1.219.

To prevent that a local client to have an IP in that range we can modify the /etc/config/dhcp file to restrict the attribution of the IP in an non overlapping range. Modify the lan section of that file like following:

config 'dhcp' 'lan'
        option 'interface' 'lan'
        option 'ignore' '0'
        option 'start' '50'
        option 'limit' '150'

The local client will only have an IP in the range of 192.168.1.50 to 192.168.1.150. Restart dnsmasq to take it into account:

/etc/init.d/dnsmasq restart

You can start the server with the following command:

/etc/init.d/openvpn start

To have it start automaticaly when the OpenWT box starts just run the following command:

/etc/init.d/openvpn enable

Bridging of the interfaces

To be able to link the OpenVPN tunnel, we need to bridge the interfaces. It an be done in the web interface or in the /etc/config/network file. In the lan section add tap0 to the ifname option:

config 'interface' 'lan'
        option 'type' 'bridge'
        option 'proto' 'static'
        option 'ipaddr' '192.168.1.1'
        option 'netmask' '255.255.255.0'
        option '_orig_ifname' 'eth0.0 wl0'
        option '_orig_bridge' 'true'
        option 'ifname' 'eth0.0 tap0'

Client configuration

Now that the OpenVPN server is running we just have to connect to it. In addition to the personal key and certificate and of the CA certificate the user will need also a configuration file. They should look like the following:

# OpenVPN on bridge OpenWRT

client
tls-client
# Which device to use
dev tap
# Which protocol
proto udp
# The OpenWRT external address
remote x.x.x.x 1194

resolv-retry infinite
nobind

persist-tun
persist-key

# The different used keys
ca ca.crt
cert user1.crt
key user1.key

# Use compression
comp-lzo
; verb 3

Now you should be able to connect to your home network from the web.

Source

Easy OpenVPN server setup guide

RTSP through OpenWRT

2013-03-03T17:36:49+01:00

The French ISP Free provide TV over DSL. Some of the channels could be directly seen on a computer through the RTSP protocol. However it is not something that is working nicely through a home switch that is just behind the FreeBox DSL router like an OpenWRT running box.

Several solution exist on the net however major part of them required static port forwarding linked with configuration of VLC (The recommended client). Here we will see how to allow it without all this strong and static configuration with the help of two kernel module that will track the RTSP connexion, open the correct port in the firewall and routes the packet to the VLC client. These two modules are ip_nat_rtsp et ip_conntrack_rtsp

To process only the kmod-ipt-nathelper-extra package need to be installed on the OpenWRT box. Do either through the web interface or through ssh with the help of opkg. After installation check that the two requiered modules are loaded with the two following commands on the OpenWRT box:

insmod ip_conntrack_rtsp
insmod ip_nat_rtsp

If its answer that insmod: a module named ip_nat_rtsp already exists, it means that the module is already loaded.

Now you just have to launch you preferred player and start watching.

Source

Openwrt et Free multiposte

OpenWRT wifi toggle

2013-03-03T17:01:46+01:00

The WRT54GL router has two buttons: one reset button and one called "SecureEasySetup" or SES. After OpenWRT installation this two button do not served. We will see how to give a role to the SES one to toggle the wifi on and off.

Wifi toggle script

First we will create a script that allow us to change the wifi status. It will activate the wifi when it is not and inactivate it otherwise. In addition it will change the WLAN LED status according to the wifi status.

For that, we will create the file /sbin/woggle (for wifi toogle), that contain:

#!/bin/sh

case "$(uci get wireless.@wifi-device[0].disabled)" in
   1) uci set wireless.@wifi-device[0].disabled=0
      wifi
      echo 1 > /proc/diag/led/ses_white
   ;;
   *) uci set wireless.@wifi-device[0].disabled=1
      wifi
      echo 0 > /proc/diag/led/ses_white
      echo 2 > /proc/diag/led/wlan
   ;;
esac

The script first grabs the wifi status (uci get wireless.@wifi-device[0].disabled). If it deactivated (ie equal to 1), it actives it and switch on the LED of the SES button. Otherwise it deactivates the wifi switch off the LED of SES button and let the WLAN LED blink once.

After creation do not forget to set it executable with the following command:

# chmod +x /sbin/woggle

To change the wifi status and test the command, you can run the script with the following command:

# /sbin/woggle

Link with the SES button

Now that e have the script to toggle the wifi, we need to link it with the SES button. Like this it will be execute each time the SES button is pressed.

It is handle by the hotplug events. For this it is needed top create the button directory in the /etc/hotplug.d directory. Then in that newly created directory create a script with a name like the following 01-radio-toggle contenting:

#!/bin/sh
if [ "$BUTTON" = "ses" ] && [ "$ACTION" = "pressed" ] ; then
  ( sleep 1; /sbin/woggle ) &
fi

Now to activate or deactivate the wifi you only need to press the SES button.

Sources

Wifi Toggle

SyncML and Horde

2012-10-02T00:39:15+02:00

Horde is a groupware framework that combine a lot of PIM data. One of the major problem with PIM data is to get them synchronized among different device. One of the most used to do so is SyncML that allow the two-way synchronization of PIM. Horde embeds a SyncML interface.

evolution and its PIM data storage

syncevolution is a software that allow the synchronization of the data contained inside the evolution PIM data management software through SyncML. However, there is no need to install evolution software to be able to synchronize the data, the storage used is independent to the presence or not of evolution and is using widely used standard like iCalendar files for calendars.

By default, they are stored in ~/.local/share/evolution/ directories. For example calendars are stored in the calendar sub-folder and tasks in the tasks sub-folder, each of them as an unique iCalendar file (respectively ~/.local/share/evolution/calendar/system/calendar.ics and ~/.local/share/evolution/tasks/system/tasks.ics)

Installation

On Debian, syncevolution is packaged. Therefore, to install it :

# apt-get install syncevolution

It will also install [[!debpkg evolution-data-server]] package that will the handling of the data in the format used by evolution.

By default, syncevolution will synchronized the data between the different peers and the evolution database. We will see how to synchronized it with Horde database.

The first thing is to create a new peer. For that we will use a template. To get the list of all templates available just enter the following command:

$ syncevolution --template ? test

You can put what ever you want after the ? but something should be specified otherwise you will get an error. Maybe a bug of the version used.

It should return something like this:

[INFO]
[INFO] Available configuration templates (clients and servers):
[INFO]    template name = template description
[INFO]    eGroupware = http://www.egroupware.org
[INFO]    Funambol = http://my.funambol.com
[INFO]    Google_Calendar = event sync via CalDAV, use for the 'target-config@google-calendar' config
[INFO]    Google_Contacts = contact sync via SyncML, see http://www.google.com/support/mobile/bin/topic.py?topic=22181
[INFO]    Goosync = http://www.goosync.com/
[INFO]    Memotoo = http://www.memotoo.com
[INFO]    Mobical = https://www.everdroid.com
[INFO]    Nokia_N900 = Template for all Nokia phones which support contacts, notes and combined tasks+events
[INFO]    Oracle = http://www.oracle.com/technology/products/beehive/index.html
[INFO]    Ovi = http://www.ovi.com
[INFO]    ScheduleWorld = server no longer in operation
[INFO]    Sony_Ericsson_K750i = Template for old Sony Ericsson phones, with separate databases for contacts/events/tasks/memos and SyncML 1.1
[INFO]    Sony_Ericsson_W595 = Template for all current Sony Ericsson phones, with separate databases for contacts/events/tasks/memos and SyncML 1.2
[INFO]    SyncEvolution = http://www.syncevolution.org
[INFO]    SyncEvolution_Client = SyncEvolution server side template
[INFO]    Synthesis = http://www.synthesis.ch
[INFO]    WebDAV = contact and event sync using WebDAV, use for the 'target-config@<server>' config
[INFO]    Yahoo = contact and event sync using WebDAV, use for the 'target-config@yahoo' config

Configuration of the access to the Horde server.

No template already exist for Horde, but the one for Funambol is working nicely with minor adaptations. To create a new pear called MyHorde based on Funambol template just run the following command:

$ syncevolution --template Funambol MyHorde

It will set up several files and folders under the ~/.config/syncevolution/default/peers/MyHorde folder.

First edit config.ini to setup the main connexion to the SyncML server of Horde.

The first value to change is syncURL that specify the URL of the SyncML server. Just addaped it to fit your horde server:

syncURL = https://my.server.com/horde3/rpc.php

Then set the username to be used to connect to the server and finally choose to set up the password either as plain text in the configuration as the name of an environmental variable or as nothing to be asked for each synchronization.

Adaptation of the names of the PIM resources

Inside the sources/ are configured the different PIM data that can be synchronized. syncevolution is able to synchronize the address book, the calendar, the memos and the todo list each of them configured in the config.ini file of the corresponding folder.

Two main variables are set in these different files the first one sync specify if the resource should be sync and how (one way, two-way, etc…). The second one uri give the name of the resource on the server.

Here are the setting I tested:

addressbook and memo:

sync = disabled

calendar with

sync = two-way
uri = event

todo with

sync = two-way
uri = task

To launch the synchronization simply launch syncevolution with the name of the profile to use:

$ syncevolution MyHorde

That is!

Source

Howto install SyncML enabled Horde 3.3 from Debian squeeze

SOCK proxy for any application (Flash)

2012-09-12T01:00:13+02:00

Normally the plugins launch inside the web browser are using the proxy settings of the browser. However, the Flash plugin is not taking it into account, if it manage to find a direct Internet connexion. Therefore even your web browsing is going through the proxy all the connexion initiated inside the Flash plugin are not going through it, that may prevent the connexion if proxy is the only way to go out or change the IP of connexion preventing a correct service.

proxchains the wrapping of all connexion of a program to a proxy

To work around it, a solution is to use a SOCKS wrapping library to wrap any calls to the network stack with SOCKS wrappers and send them through the proxy. proxychain is such a tool. To install it:

# sudo apt-get install proxychains

You can configure it in /etc/proxychains.conf file. For example to use the SOCK 5 proxy running on localhost listening on port 8080:

dynamic_chain

tcp_read_time_out 15000
tcp_connect_time_out 10000

[ProxyList]
socks5 127.0.0.1 8080

SSH as a SOCK proxy

The classic way to have a SOCK 5 proxy server running locally is a SSH tunnel that is launch with the -D port option:

$ ssh -D 8080 user@server.net

This way all connexion going locally will be going out on server.net. The connexion need to be running so the launch application can use it.

Loading of the wrapping for a program

proxychains manage to capture all the network calls by loading a specific wrapping around the network call function. The easiest way to do it is just to run the proxychains program followed by the name of the program which connexion need to be pass to the proxy. For example to launch Iceweasel:

$ proxychains iceweasel

Resources

LDAP authentication

2012-09-07T00:49:16+02:00

How to add ldap authentication to Debian server. It suppose that a running ldap server is running and that the ldap tree is filled correctly with account informations.

libnss-ldapd installation

The client need the libnss-ldapd package that is a fork of the historical libnss-ldap for better efficiency

# apt-get install libnss-ldapd

For the configuration it ask the following information:

URI of the LDAP server. better as an IP to prevent any DNS resolution problem
The root base where to look for the information (DN)
The name services to configure: aliases, ethers, group, hosts, netgroup, networks, passwd, protocols, rpc,services, shadow. for LDAP authentication group, passwd and shadow should be selected.

Set identification credential for LDAP connexion

If the connexion to the LDAP server need an authentication you can specify it in the /etc/nslcd.conf file by uncommenting and adjusting the following variables:

binddn cn=nss,dc=example,dc=com
bindpw my_password

After modification, restart nslcd service:

# /etc/init.d/nslcd restart

Testing

To test if it is working, we need to ask for information that are store locally and in the LDAP server. To get information about account we need to use the getent command followed by the name of the database we want to retrieve.

For example to retrieve all the content of the passwd database we use the following command:

$ getent passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
[...]

It should show entries that are present on the local database but also in the LDAP directory.

We can also limit to a particular entry, like root account:

# getent passwd root
root:x:0:0:root:/root:/bin/bash

And here for root group:

# getent group root
root:x:0:admin

Home directory creation

The creation of the home directory is normally done when creating the user. However for LDAP user they might not have been created on the current system and therefore did not have any home directory. If you want that it is created automatically at the connexion of the user if it does not exist you need to edit the /etc/pam.d/common-session file and add at the end the following line:

session required        pam_mkhomedir.so skel=/etc/skel

References

New server setup

2012-09-07T00:16:15+02:00

Small process when we get a new installed with more eye-candy staff and security.

Core configuration

Locales configuration

To setup the appropates locales on the system: the one that will be available for the users.

# dpkg-reconfigure locales

Select the local according to the language you want and the different encodings. The more languages encoding you will selected the more time it will need to generate them and the more disk space it will use.

For example, to get French messages select the locales starting by fr_FR (French from France) for all encoding. The best encoding on Unix system is UTF-8. On the second screen select the default language and encoding that will be used by the system for example fr_FR.UTF-8, to get message in French by default.

Bash configuration

The creation of a new user take the default configuration files that are present in the /etc/skel/ folder. However, by default the root user do not get these files. Therefore to get a better bash shell for root with color prompt and auto-completion we have to copy the .bashrc manually:

# cp /etc/skel/.bashrc $HOME

By default the bash auto-completion is activated in that file.

To activate the color prompt uncomment the line 39:

39  #force_color_prompt=yes

to get

39  force_color_prompt=yes

Some commands can use color. To use it by default some alias could be activated in the lines 78 and following:

if [ -x /usr/bin/dircolors ]; then
    test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval "$(dircolors -b)"
    alias ls='ls --color=auto'
    alias dir='dir --color=auto'
    alias vdir='vdir --color=auto'

    alias grep='grep --color=auto'
    alias fgrep='fgrep --color=auto'
    alias egrep='egrep --color=auto'
fi

Logout and login again to get it active, or source it to get active in the current shell:

# source $HOME/.bashrc

Set a alias address for root account

By default all system email are send to the root user. However, to avoid uneeded root login it is a godd idea to redirect this email to an other account or address. For that we need to modify /etc/aliases so it contain the following line:

root: nom@domain.com

All email send to root will be send to this address.

Increase the security of the system

System upgrade

# aptitude update
# aptitude dist-upgrade

To receive by email automatically available system upgrade, you need to install apticron package

# aptitude install apticron

The message of possible upgrade will be send by email on a daily basis to root by default

fail2ban installation

fail2ban is a daemon that is monitoring connexion attempt and blacklist temporarily IP addresses after a certain amount of failed connexion from this IP. This prevent brute force attack s, that try all possible password to enter the system.

# aptitude install fail2ban

To configure it you have to edit the /etc/fail2ban/fail.conf file. Several modules are available for fail2ban and to activate them you need to go to the end of the configuration file (around the line 74). Each module is called a JAIL.

Each JAIL is setup the same way, like for example for ssh:

[ssh]
enabled = true
port    = ssh
filter  = sshd
logpath  = /var/log/auth.log
maxretry = 6

Its name is in between [], and the option enable is set to true to activate it. The port that have to be monitored is set with the port option, like the log file (logpath) and the filter to use to interpret it (filter). Finally the number of error that is allowed before an IP ban (maxretry).

By default the ssh JAIL is activated. The pam-generic JAIL allow to block the user after error on the PAM module. The ssh-ddos JAIL to protect against deny of service attacks.

To take into account the new configuration you need to restart the service with the following command:

# service fail2ban restart

rkhunter installation

It is a software that search for rootkit by searching for modification of main programs compared to safe stat and signature and to identify already known rootkits.

# aptitude install rkhunter

debsecan installation

Check for security alerts on the web in relation with the system.

# aptitude install debsecan

To configure it run

# dpkg-reconfigure debsecan

Select the correct distribution, so the alert will be in relation to it.

debsecan web site

Firewall configuration with ferm

See the corresponding article about ferm

SSH connexion limitation

Do not deactivate the SSH connexion for the root user without any other account on the system: you will not be able to connect to the server anymore.

First create a user (admin in this example) that will be able to connect as root after the deactivation of the SSH connexion for root user.

# adduser admin

When configured, the SSH connexion for root user can be deactivated in the /etc/ssh/sshd_config file:

26  PermitRootLogin no

Restart SSH server to take it into account.

# /etc/init.d/ssh restart

Limitation of the su command only to certain users

It is highly suggested to keep a connected root console on the server until the configuration is working et to confirmed that we can become root before closing it. In case of error, it might prevent any connexion as root.

The su command allow to change user in a console to execute a program. The main case is the switch to root for administration tasks. However, it could be nice to limit this possibility to certain user. By default su can be executed by any user, assuming he knows the password of the targeted user. It is possible to limit this possibility to a particular group by modifying the PAM configuration file of su (/etc/pam.d/su). The following should be uncommented:

15  auth       required   pam_wheel.so

By default, the user should belong to the root group to be able to use su. Historically, the super-user group is called wheel therefore the name of the PAM module (see [[!wikipedia Wheel_(Unix_term)]] for more info). It is possible to change the wheel group to consider by adding the group=group_name option to the command. Therefore to set the adm group as wheel group:

15  auth       required   pam_wheel.so group=adm

Then you just have to add the user you want to allow to connect as root in the correct group. For example to add the admin user to the root group:

# adduser admin root

Sources

po regex

2012-09-04T00:42:19+02:00

Some notes to be able to construct a small program able to apply a regex to translated string of a po file

Will be done certainly in python:

polib python module to be able to handle the po files seems quite simple to use according to the Quick start guide. In addition polib is included in Debian repository.
Finally the python regex module re. The official Howto on regex in python. The regex are not set as in perl but with a regex, the on the perl regex the two parts could be extract easily.
command line arguments parse with argparse as usual

Redirecting sderr to a pipe

2012-07-31T11:36:06+02:00

Programs are sending message on two different steam of data: standard output and standard error. Standard output, notes as stdout, is where the program is writing the output data. Standard error or stderr is to output the error messages or diagnostics. With this two stream we can therefore separate between these two kind of output and process them separately. A third stream of data exist, that is standard input or stdin, which correspond to the entry of data for a program.

Classical shell programming involved to play with these different stream of data, where the stdout of one program is pipe to the stdin of an other program to get the desired functionality. One of this task is to filter the output of a command with grep.

$  ls -1
Desktop
Documents
Pictures
Videos
Download
Music

$  ls -1 | grep D
Desktop
Documents
Download

However, pipe is only for redirection of stdout to the stdin. Sometime we would like to filter the stderr and not the sdtout. Therefore we need to redirect the stream so they can be processed correcrtly.

First we can redirect stderr to stdout and mix the two output that will be then filtered:

$ myprog 2>&1 | grep something

In the same time we can destroy the output of stdout and only keep stderr to be filtered:

$ myprog 2>&1 > /dev/null | grep something

You have to be carefull in the order of the command since the following do not seems to work as expected, both stream being redirected to /dev/null

$ myprog > /dev/null  2>&1| grep something

Source

How can I redirect stderr to a pipe?

Mounting a ext formated disk on FreeBSD

2012-07-27T18:16:53+02:00

Disk naming are a little bit different between BSD and Linux. In addition ext2/ext3 file system are not so nicely support. However, you can mount your disk to read then.

List the disk available on the system

To get the list of connected disk to the system enter the following command:

camcontrol devlist

It will output something as follow:

<VBOX HARDDISK 1.0>   at scbus0 target 0 lun 0 (ada0,pass0)
<VBOX CD-ROM 1.0>     at scbus1 target 0 lun 0 (pass1,cd0)

To get the partitions available:

ls /dev/ada0*

Mounting the filesystem

mount -t ext2fs /dev/ad0s1 /mnt/linux

Reinstallation of the same packages on Debian

2012-07-27T18:16:53+02:00

For the transfer of a Debian or Ubuntu machine, or to make a mirror of it, it is often needed to reinstall the packages that are installed one one system on an other one. We will explain it in here.

The dpkg way of doing

First of all, we need to grab the list of all installed package and save it in a text file. Here we will save it in installed_packages.txt.

# dpkg --get-selections > installed_packages.txt

The installed_packages.txt file contain a list of package and their installation status:

aalib1                                          deinstall
abiword-common                                  deinstall
acroread                                        install
acroread-debian-files                           install
acroread-escript                                install
acroread-plugins                                install
adduser                                         install
adept-notifier                                  deinstall
affix                                           install
akode                                           deinstall
akregator                                       install
alsa-base                                       install
alsa-oss                                        install
alsa-tools                                      install
 [...]

After transferring the list of packages on the new system we need to load it inside dpkg, with the following command:

# dpkg --set-selections < mes_paquets

Then, we need to say to apt-get to grab this selection to set the package to install and remove:

# apt-get dselect-upgrade

Finally a classical upgrade is required:

# apt-get dist-upgrade

The aptitude way of doing

Grabs the only the manually installed packages on the current system in installed_packages.txt:

# aptitude search -F%p ~i\!~M > installed_packages.txt

The installed_packages.txt file contain a list of package, without status unlike for the dpkg way:

aalib1
abiword-common
acroread
acroread-debian-files
acroread-escript
acroread-plugins
adduser
adept-notifier
affix
akode
akregator
alsa-base
alsa-oss
alsa-tools
 [...]

After transferring the list of packages on the new system, we just have to give it to aptitude or apt:

# aptitude install $(cat installed_packages.txt)

# apt-get install $(cat installed_packages.txt)

The advantage of this method is that only the manually installed packages will be installed, with corresponding dependency. It will therefore set correctly the database use to detect the manually installed packages, and not with all the packages that were installed on the first system.

Resource management links

2012-07-06T14:02:58+02:00

Description:

The Simple Linux Utility for Resource Management (SLURM) is an open source, fault-tolerant, and highly scalable cluster management and job scheduling system for large and small Linux clusters. SLURM requires no kernel modifications for its operation and is relatively self-contained. As a cluster resource manager, SLURM has three key functions. First, it allocates exclusive and/or non-exclusive access to resources (compute nodes) to users for some duration of time so they can perform work. Second, it provides a framework for starting, executing, and monitoring work (normally a parallel job) on the set of allocated nodes. Finally, it arbitrates contention for resources by managing a queue of pending work.

—SLURM: A Highly Scalable Resource Manager

SLURM: A Highly Scalable Resource Manager Official SLURM website
Example job submission files

po files handling

2012-07-05T22:41:31+02:00

po files are used by programs to translate the messages in different languages. Thus they contain a list of all translatable strings extracted from the code and their corresponding translation, in a given language. Here are given some information to manipulate and few resources to help the translation, mainly derived from experiments in for Debian project translation to French.

File formating

For ease of reading text files on any type of screen it is common to limit the size of their line to 80 characters. The following command allows to cut the lines at 80 characters while maintaining the specific labeling of po files:

$ msgcat fr.po -o fr.po

You can specify the length of a line to another value if necessary with the -w option. So to format a po file with 40 characters:

$ msgcat -w40 fr.po -o fr.po

Update of a file while already start the translation

When translating sometimes the original po file have been updated while your translation is not finished. The following command can update your po file (fr.po) with new data from the new file (fr.new.po):

$ msgmerge --update --previous fr.po fr.new.po

You can continue on your translation on the updated fr.po file.

Resources

General

Translation proposition database based on already translated FLOSS projects: http://open-tran.eu/

Debian specific (French translation team)

Help

Status and coordination

LanguageTool for Vim

2012-06-07T13:52:33+02:00

LanguageTool is an Open Source style and grammar proofreading software. It is a good complement to the spell checking program already in use in a lot of software.

It is written in Java and aimed to be integrated easily in OpenOffice.org/LibreOffice as a plugin. But it can also be used as a stand-alone GUI application, embedded in other Java applications or as a server service.

It exists also a command line interface that can be integrated as a tool inside Vim.

LanguageTool installation

First of all download the last version of LanguageTool form its website. It is under the form of a OpenOffice.org/LibreOffice plugin, so with an .oxt extension. In fact it is a zip archive and for installing it you need to unzip it in the folder of your choice. In our example we will install it in ~/lib/LanguageTool directory.

$ mkdir -p ~/lib/LanguageTool
$ mv LanguageTool-1.7.oxt ~/lib/LanguageTool/
$ cd ~/lib/LanguageTool
$ unzip LanguageTool-1.7.oxt

To be able to run it you will need the version 6 of Java. Therefore if you do not already have it just install it:

# apt-get install openjdk-6-jre

Installation of the Vim binding

Thanks to Dominique Pellé a Vim plugin exist to be able to run LanguageTool from within Vim.

Download the last version from its description page and install it on your .vim directory:

$ mkdir -p ~/.vim
$ cd ~/.vim
$ unzip /path-to/LanguageTool.zip
$ vim -c 'helptags ~/.vim/doc'

Then you need to define the path to LanguageTool.jar inside your .vimrc:

let g:languagetool_jar=$HOME . '/lib/LanguageTool/LanguageTool.jar'

Use of LanguageTool inside Vim

You need to specify the language of your text inside Vim with command spelllang. For example to set the language to French enter :set spelllang=fr.

To run LanguageTool on the current buffer just run :LanguageToolCheck. If you use the example text of LanguageTool:

Paste your own text here... or check this text too see a few of the problems
that that LanguageTool can detect. Did you notice that their is no spelcheckin
included?

Which should give you an output like this:

# java -jar /home/tblein/lib/LanguageTool/LanguageTool.jar -c utf-8 -d WHITESPACE_RULE,EN_QUOTES -l en --api /tmp/vtjmKYQ/3

Error:      1/2 (TOO_TO:1) @ 1L 48C
Message:    Did you mean 'to see'?
Context:    ...ste your own text here... or check this text too see a few of the problems that that LanguageTool...
Correction: to see

Error:      2/2 (THEIR_IS:1) @ 2L 21C
Message:    Did you mean 'there'?
Context:    ...LanguageTool can detect. Did you notice that their is no spelcheckin included?
Correction: there

Resources

Perl and UTF-8

2012-05-08T01:20:03+02:00

Like with python, the handling of [[!wikipedia UTF-8]] string in perl is not straight forward since this language was not originally design to handle Unicode strings of characters.

Correct length of UTF-8 string

[[!wikipedia ASCII]] characters are coded on 8bits that is on one octet. That explain the limited number of different characters and the different encodings according to language. Unicode try to solve it by encoding it on several a dynamic number of octet depending of the characters. Therefore some characters are only coded on one octet (the one that are present in the [[!wikipedia ASCII]] set) some other on two octets.

By default in perl the strings are [[!wikipedia ASCII]] and therefore to determine their length with the length function it only count the number of octet. That fit perfectly when the characters are coded only on one octet but in a lot of language the some used characters are coded on several octets. The length is therefore longer, for example in the following script:

#! /usr/bin/env perl
my $string = "Ceci est une chaîne avec trois caractères codés sur deux octets";
print length($string) . "\n";

$ ./test.pl
66

In fact there are 63 characters in this string.

To get the real string length a conversion of the format is needed. For that the Encode module need to be use to decode the [[!wikipedia UTF-8]] string before measuring its length:

#! /usr/bin/env perl
use Encode;
my $string = "Ceci est une chaîne avec trois caractères codés sur deux octets";
print length(Encode::decode("utf-8", "$string")) . "\n";

$ ./test.pl
63

This time the correct size of the string is returned

Wide character in print

When printing some [[!wikipedia UTF-8]] string on the console it may append that the following error appear:

Wide character in print at test.pl line 3.

To remove of it just add the folling entry at the beginning of your script:

use encoding "utf-8";

Resources

Wide character in print… warning in Perl

Installation of a CAcert certificate for lighttpd

2012-05-01T22:35:45+02:00

Here we will see how to set up a X.509 certificate signed by CAcert on lighttpd web server

TLS/SSL

[[!wikipedia Transport_Layer_Security]] best known as TLS/SSL is a cryptographic protocol use on Internet to encrypt communications. It using both asymmetric encryption for key exchange and symmetric encryption for the rest of the communication. Therefore, one server private key and the corresponding server certificate are needed.

The confidentiality of the exchanges is mainly based on the certificate. To be sure that we get the server certificate from the correct server it is be signed by some [[!wikipedia Certificate_Authority]]. The [[!wikipedia Certificate_Authority]] is often a third party that is recognize by the two actors. The most known are [[!wikipedia VeriSign]], [[!wikipedia GoDaddy]] and [[!wikipedia Comodo]]. However, they are quite expensives.

Get a signed certificate by CAcert

CAcert is a community driven, Certificate Authority that issues certificates to the public for free. To get a signed certificate just register on the web site.

You will need to install the ssl-cert and ca-certificates to be able to generate the server private key and a certificate signing request (CSR). To generate CAcert provide a small shell script csr. After downloading it just run it and answer the questions:

$ csr.sh
Private Key and Certificate Signing Request Generator
This script was designed to suit the request format needed by
the CAcert Certificate Authority. www.CAcert.org

Short Hostname (ie. imap big_srv www): www
FQDN/CommonName (ie. www.example.com) : *.example.com
Type SubjectAltNames for the certificate, one per line. Enter a blank line to finish
SubjectAltName: DNS:*.example.com
SubjectAltName: DNS:
Running OpenSSL...
Generating a 2048 bit RSA private key
......+++
...............................................................+++
writing new private key to '/home/user/www_privatekey.pem'
-----
Copy the following Certificate Request and paste into CAcert website to obtain a Certificate.
When you receive your certificate, you 'should' name it something like www_server.pem

-----BEGIN CERTIFICATE REQUEST-----
MIIBzTCCATYCAQAwgYwxCzAJBgNVBAYTAmdiMQ8wDQYDVQQIEwZMb25kb24xDzAN
BgNVBAcTBkxvbmRvbjEZMBcGA1UEChMQU3BhY2VTdXJmZXIgTHRkLjEZMBcGA1UE
AxMQd3d3LnNwYWNlcmVnLmNvbTElMCMGCSqGSIb3DQEJARYWd2VibWFzdGVyQHNw
YWNlcmVnLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAywfuXnd348ot
iAcZ4RHFc509ImCTagKaNkiQ4xyijbPYP7H0UQ5iXqvojSIcbUOVhExqwqyqjCPm
7ZpON3IXktIcKAwPFvoqKkHuqTa8KMnZTSY8P7QILYHFd2Sd1l1arCrWv8HWb+qM
RHVTlviBaLAHQxnz28qKkYN09K0fw5cCAwEAAaAAMA0GCSqGSIb3DQEBBAUAA4GB
AFMgp2KkHQXMC1JbZf3AkIz7mrl4X21cRusTfd8ec3RuMZexGy76jMGFyPWVM69R
Fvpfiic8h28HrHube7pEPFpdUSj2cR4OZCAg5uqzN/ESwc4CtLzej7pWoDPpc/kv
hiJ/eGOxINKd39kCuzIS6zrvb2ihJth7jcmokezmrwjQ
-----END CERTIFICATE REQUEST-----

The Certificate request is also available in /home/user/www_csr.pem
The Private Key is stored in /home/user/www_privatekey.pem

Submit your CSR to CAcert web site and save the resulting signed private key in a file in the /etc/ssl/private folder: server_certificate.pem

To check its validity run openssl command with the action verify on it:

$ openssl verify server_certificat.pem
server_certificat.pem: OK

You should get OK.

Inclusion of the certificate to be handle by lighttpd

To be able to encrypt data with lighttpd the server certificate, the server private key and the certificate authority certificate should be given to lighttpd. The private key and the server certificate should be combined in one file with a command like the following:

# cat /etc/ssl/private/server_privatekey.pem /etc/ssl/certs/server_certificate.pem \
   > /etc/ssl/private/lighttpd.pem

Then change the access right of this file to readable only by the owner and the group owner and writable by the owner. This very important to set it up like this since anybody who have access to this file will be able to decrypt all the encrypt traffic of the server.

# chgrp www-data /etc/ssl/private/lighttpd.pem
# chmod 640 /etc/ssl/private/lighttpd.pem

Then you need to configure lighttpd for example in /etc/lighttpd/conf-enabled/10-ssl.conf on Debian to take into account the certificate:

$SERVER["socket"] == "0.0.0.0:443" {
    ssl.engine = "enable"
    ssl.ca-file = "/usr/share/ca-certificates/cacert.org/cacert.org.crt"
    ssl.pemfile = "/etc/ssl/private/lighttpd.pem"
    ssl.cipher-list = "ECDHE-RSA-AES256-SHA384:AES256-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH:!AESGCM"
    ssl.honor-cipher-order = "enable"
}

The ssl.ca-file entry specify the certificate authority certificate and ssl.pemfile the server privat key and certificate file.

You just need to restart lighttpd and your certificate should be available.

# /etc/init.d/lighttpd restart

Resources

Preventing multiple executions of a Makefile

2012-05-01T17:21:48+02:00

Often the automatic builds are controlled by the make tools using the rules defined in so named Makefile. make is very nice since it allow a smooth control of the build with a direct link with dependencies. Therefore only what is need to be build is built. A rule is executed only when the dependencies are younger than the target for that rule.

To automate the builds regularly the construction might be run regularly via cron jobs. However, if the time in between the make runs is smaller than the time required to perform a particular task, this task will be run several time and filled the resources of the computer. To prevent it we can setup a protection on the Makefile to prevent it to be executed several times at a given time.

Lock file

To prevent the multiple execution of the Makefile we will use a so called lock file. When the Makefile is execute it will create a file with a particular name. This is our lock file. When it finish to execute, it just delete this file. In case the Makefile is run a second time in parallel, it will see that the lock file exist and stop the processing.

Setting up lock files inside a Makefile

To determine the existence of the file we will use the unix command ls that will return the name of the lock file if it exist else nothing. We will catch it in a make variable:

LOCKFILEEXIST = $(shell ls $(LOCKFILE) 2> /dev/null)

Then we test if this variable is empty or not. In case it is not empty, we exit with an error:

ifneq ($(LOCKFILEEXIST), )
$(error "already running")
endif

In case we the lock file does not exist we continue the process and set the lock file.

$(shell touch $(LOCKFILE))

Then follow the rest of the Makefile like usual. We just need to remove the lock file at the end of the rpocessing. For this we add it at the end of the all rules that is the main run.

all:
    @echo "processed"
    $(shell rm -f $(LOCKFILE))

This command should be add to all rules that terminate the run, otherwise future run might be blocked even no Makefile is running

Testing it

The final test Makefile:

# Definition of the lockfile
LOCKFILE = "test.lock"

# Search for the lock file
LOCKFILEEXIST = $(shell ls $(LOCKFILE) 2> /dev/null)

# if the lock file exist exit
ifneq ($(LOCKFILEEXIST), )
$(error "already running")
endif

# Create the lock file
$(shell touch $(LOCKFILE))

# process and remove the lock file
all:
    @echo "processed"
    $(shell rm -f $(LOCKFILE))

Without any lock file the execution is done and like this several time:

$ make all
processed
$ make all
processed

When a lock file exist the Makefile stop with an error:

$ touch test.lock
$ make all
 Makefile:5: *** "already running". Stop.

Writting UTF-8 strings in python

2012-05-01T14:48:48+02:00

When processing some strings in python you may have to deal with special characters. You test your code with some output on the standard output and everything is working. However when you want to write your string you have complains like the following:

UnicodeError: ascii codec can't decode byte 0x85 in position 255: oridinal not in range(128)

What is the problem?

The problem comes from the fact that when writing in the file, python use the [[!wikipedia ASCII]] coding that code characters on 8bits and have only 128 different characters, while your string is encodes with a higher number of characters. On most current Unix the default character encoding is [[!wikipedia UTF-8]] that code characters with a variable number of bits. So it may appends that some of the characters you want to write are no more in the set of [[!wikipedia ASCII]]. There is no problem when printing on the standard output, because your console is certainly in [[!wikipedia UTF-8]] also.

How to solve it?

In python there are to sort of structures that handle list of characters: strings and unicode. The strings are using [[!wikipedia ASCII]] and unicode are using Unicode as their name shows it.

To be able to write a string encodes with [[!wikipedia UTF-8]] you first need to transform it as unicode.

> my_utf8_string = "A string with some UTF-8 characters °"
> my_utf8_string
'A string with some UTF-8 characters \xc2\xb0'
> converted_string = unicode(my_utf8_string, "utf-8")
> converted_string
u'A string with some UTF-8 characters \xb0'

Then you need to open the file as [[!wikipedia UTF-8]] with the codecs python module and save your unicode string as with a normal file handling.

import codecs
with codecs.open("/tmp/test", "w", encoding="utf-8") as outFile:
    outFile.write(converted_string)

That's all.

Resources

Xerox Phaser 6010N on Debian 64bits

2012-04-30T22:22:38+02:00

Xerox gives the drivers only for 32bits Linux boxes. The installation of the drivers under 64bits is not strait forward, therefore here is a small guide on how to install a Xerox Phaser 6010N on Debian Wheezy 64bits (amd64). It should work similarly on any Squeeze box.

For the inpatients

Here is the fast content:

install core 32bits libraries (ia32bits);
install manually a 32bits version of the libcupsimage2 library in /usr/lib32/;
install the Xerox Phaser 6010 32bits package;
configure the printer with the driver.

Installation of 32bits libraries

If not already done install the core 32bits libraries on your 64bits installation with the following command:

# apt-get install ia32-libs

Installation of the Xerox drivers

Go to Xerox web site to download the Phaser 6010 deb package on the Linux page. Select English as language since the complete drivers are only available in English.

To install it you need to force the architecture since it is a 32bits (i386) package:

# dpkg -i --force-architecture xerox-phaser-6000-6010_1.0-1_i386.deb

Configure the printer

Install and configure the printer with the proposed Xerox driver. Normally until know you should not get any error. However when trying to print it cannot success.

In Cups logs you can see that a library is missing: libcupsimage.so.2

Installation of a 32bits version of libcupsimage2

libcupsimage is not included by default in the 32bits library of Debian therefore you will need to install it by hand. For that just go to Debian web site and download the 32bits package of libcupsimage2

Uncompress it in a temporary folder (ia32 for example) with the following command

$ dpkg -X libcupsimage2_1.5.2-5_i386.deb ia32/

You need then to copy the library at its correct place as root (/usr/lib32):

# cp ia32/usr/lib/i386-linux-gnu/libcupsimage.so.2 /usr/lib32/

To take it into account you need to update the library used by the dynamic linker just run the following command as root:

# ldconfig

You can launch another print and that time it should work.

You have to be careful since the library was not installed with the package manager therefore it will not be automatically updated.

PDF manipulation on command line

2012-04-26T10:23:16+02:00

Tools

Pdftk a general command line tool box
PDFjam a set of shell script using the pdfpages LaTeX package for pdf processing

Command examples

Combines different pdf in one (Pdftk)

Fixed list the order of input file is important, combine 1.pdf, 2.pdf and 3.pdf in 123.pdf

$ pdftk 1.pdf 2.pdf 3.pdf cat output 123.pdf

All the pdf of the directory by alphabetic order in all.pdf file:

$ pdftk *.pdf cat output all.pdf

Puts several page on one sheet (PDFjam)

Two page per sheet on top of each other

$ pdfnup --nup 1x2 input.pdf

Two page per sheet on side by side

$ pdfnup --nup 2x1 input.pdf

Sources

Official Pdftk examples

Installation d'un serveur OpenVPN

2011-09-05T00:00:00+02:00

Installation du serveur

# aptitude install openvpn

Génération des certificats et clés

Tout se passe dans le repertoire /usr/share/doc/openvpn/examples/easy-rsa/2.0/ Pour s'y rendre:

# cd /usr/share/doc/openvpn/examples/easy-rsa/2.0/

Ensuite il faut modifier les valeurs du fichier vars en accord avec nos paramètres avec notamment:

64  export KEY_COUNTRY="FR"
65  export KEY_PROVINCE="France"
66  export KEY_CITY="Petaouchnok"
67  export KEY_ORG="Ma Boite"
68  export KEY_EMAIL="ma@maboite.fr"

une fois le fichier vars complété il faut initialisé les variables à l'aide de la commande:

# source vars

Une remise à zéro de la génération de certificat dans le sous dossier keys s'effectue à l'aide de la commande suivante :

# ./clean-all

Génération du certificat et de la clé de l’autorité de certification (CA)

Il s'agit du certificat principal du serveur qui va être utilisé par tous les nœud pour la signature des différents certificats et clés. Ainsi en utilisant la clé le certificat va pouvoir contrôler la provenance des certificats présentés par les clients. Pour les générer :

# ./build-ca

Il suffit de répondre par défaut au questions qui ont été pré-remplies par le fichier vars. Seul l'entrée Common Name n'est pas remplie. Il s'agit du nom du serveur. Le certificat est créé dans le fichier keys/ca.crt et la clé correspondantes dans le fichier keys/ca.key.

Génération du certificat et de la clé du serveur

Il s'agit du certificat et de la clé qui permettront d'identifier le serveur. Le script suivant permet de générer la clé NomDuServeur.key et le certificat NomDuServeur.crt :

# ./build-key-server NomDuServeur

Vers la fin de ce script il est demandé un mot de passe. Si un mot de passe est entré, à chaque démarrage du serveur OpenVPN il faudra entrer ce mot de passe. Dans le cas contraire il n'y en aura pas besoin, mais une personne possédant la clé pourra l'utiliser sans contrainte.

Génération du certificat et de la clé pour chaque client

Pour les clients un script comparable existe. Ainsi pour obtenir le certificat et la clé pour un client lambda :

# ./build-key lambda

La clé keys/lambda.key et le certificat keys/lambda.crt sont ainsi créer. Comme précédemment pour la clé du serveur concernant le mot de passe. Il faut répéter cette procédure pour chaque client différents.

Création du paramètre Diffie Hellman

# ./build-dh

qui va créer le fichier keys/dh1024.pem

Configuration du serveur OpenVPN

Il faut déplacer les certificats et la clé créés pour le serveur dans le répertoire principale de OpenVPN (code:/etc/openvpn/), a savoir le certificat et la clé de l’autorité de certification (code:ca.crt et ca.key), le certificat et la clé spécifiques du serveur (code:NomDuServeur.crt et NomDuServeur.key) et le fichier du paramettre de Diffie Hellman (code:dh1024.pem)

# cp /usr/share/doc/openvpn/examples/easy-rsa/2.0/keys/ca.crt /etc/openvpn/
# cp /usr/share/doc/openvpn/examples/easy-rsa/2.0/keys/ca.key /etc/openvpn/
# cp /usr/share/doc/openvpn/examples/easy-rsa/2.0/keys/NomDuServeur.crt /etc/openvpn/
# cp /usr/share/doc/openvpn/examples/easy-rsa/2.0/keys/NomDuServeur.key /etc/openvpn/
# cp /usr/share/doc/openvpn/examples/easy-rsa/2.0/keys/dh1024.pem /etc/openvpn/

Une fois les différents fichier en place il faut créer un fichier de configuration pour le serveur. Pour cela le plus simple est de partir à partir du fichier d'exemple contenu dans

# cd /usr/share/doc/openvpn/examples/sample-config-files/
# gunzip server.conf.gz
# cp server.conf /etc/openvpn/

Configuration du serveur comme point d'accés

Configuration du pare-feux ferm

Mise en place du NAT des adresses:

table nat {
        chain POSTROUTING saddr 10.8.0.0/255.255.255.0 MASQUERADE;
}

Autoriser les connexions depuis l'interface du vpn dans la table filter et la chaine INPUT :

interface tun0 ACCEPT;

Autoriser le transfert de paquets venant du vpn chaine FORWARD :

interface tun0 ACCEPT;

Autoriser le forward IPv4

De manière temporaire:

# echo 1 > /proc/sys/net/ipv4/ip_forward

De manière permanente en définisant dans le fichier /etc/sysctl.conf l'option net.ipv4.ip_forward à 1:

net.ipv4.ip_forward=1

Sources

Installation d'un serveur pptpd

2011-08-30T00:00:00+02:00

PTP est un protocole de tunnel de point à point permettant de créer des réseaux privés [[wp>Point-to-Point_Tunneling_Protocol]]. Conçut par Microsoft, il est moins robuste que les solutions VPN récentes comme OpenVPN, IPSec mais a l'avantage d'être implémenté d'office dans Windows et est plus facilement accessible que les autres solution de VPN sur certains appareils (HP TouchPad). Nous alons voir ici comme le mettre en place sur un serveur Debian (Squeeze) en utilisant le serveur poptop (paquet pptpd).

Installation et configuration du serveur

# aptitude install pptpd

Adresses

La configuration a lieu dans le fichier /etc/pptpd.conf. Vous devez y préciser l'adresse IP privé du serveur ainsi que la plage d'adresse IP utilisées par les clients. Par exemple pour un serveur ayant pour adresse privé 10.8.1.1 et des clients entre les adresses IP 10.8.1.10 à 10.8.1.20:

localip 10.8.1.1
remoteip 10.8.1.10-20

Utilisateurs

Pour se connecter au serveur les utilisateurs doivent spécifié un nom d'utilisateur et un mot de passe. Ils sont spécifiés dans le fichier /etc/ppp/chap-secrets.

Pour cela pour et pour chaque utilisateur il suffit d'ajouter une ligne comme la suivante:

client    server  secret          IP addresses
monlogin    *     monmotdepasse       *

Règles du pare feux

Le VPN ppptp utilise le port 1723 il faut donc l'ouvrir pour pouvoir s'y connecter. Ainsi avec ferm:

table filter {
  chain INPUT {
    proto tcp dport 1723 ACCEPT;
  }
}

Une fois les utilisateurs connectés et si vous considérez que vos utilisateurs sont sures vous pouvez ouvrir les ports en provenance du VPN:

table filter {
  chain INPUT {
    interface ppp0 ACCEPT;
  }
}

Accès internet à travers le VPN

Cela permet aux utilisateurs du VPN d'accéder au reste du réseau et internet à travers le VPN.

Activation du transfert des paquets IP au niveau du noyau

Cela s'effectue via la commande suivante :

# echo 1 > /proc/sys/net/ipv4/ip_forward

Pour le rendre permanent il suffit de décommenter dans le fichier /etc/sysctl.conf la ligne :

net.ipv4.ip_forward=1

Règles du pare-feux

Dans un premier temps il faut autoriser le transfert de paquets IP en provenance du VPN. Par exemple avec ferm:

table filter{
  chain FORWARD {
    interface ppp0 ACCEPT;
  }
}

Ain si la translation d'adresse en provenance des adresses du réseau VPN. Par exemple avec ferm :

table nat {
  chain POSTROUTING saddr 10.8.1.0/255.255.255.0 MASQUERADE;
}

Mise en place d'un serveur DNS

Lors des connexions internet le serveur DNS est primordial pour associer les URL avec les adresses IP correspondantes. Afin que les clients puissent utiliser un service DNS facilement il est possible d'installer le cache de DNS dnsmasq:

# aptitude install dnsmasq

Configuration d'un client sous Linux

Pour se connecter au VPN depuis Linux il suffit d'installer le paquet pptp-linux:

# aptitude install pptp-linux

La configuration se fait dans les fichiers du répertoire /etc/ppp. Les mots de passe et accès sont spécifiés dans le même fichier que pour le serveur à savoir /etc/ppp/chap-secrets. Ainsi comme pour l'utilisateur du VPN précédent:

client    server  secret          IP addresses
monlogin   PPTP   monmotdepasse       *

Ensuite pour facilité la création du tunnel il faut créer un fichier (mon_vpn dans notre exemple) dans le répertoire /etc/ppp/peers/ contenant par exemple:

pty "pptp mon_vpn.example.net --nolaunchpppd"
name tblein
remotename PPTP
require-mppe-128
file /etc/ppp/options.pptp
ipparam mon_vpn

On initialise le tunnel via la commande:

# pon mon_vpn

Pour l'arrêter :

# poff mon_vpn

Afin que les connexions passe par le tunnel il suffit de modifier les routes par défaut.

TODO

Sources

Exécuter une commande lors de la connexion

2016-07-27T00:00:00+02:00

Sous Linux la connexion est gérée par le système d’authentification PAM (Pluggable Authentication Modules). Comme son nom l'indique tout se passe dans différents modules qui permettent d'ajouter des fonctions comme différents systèmes pour l’authentification (LDAP, NSS) ou alors des fonction à exécuter lors de la connexion (montage de répertoires).

pam_exec

Le module pam_exec permet d'exécuter une commande arbitraire lors de la connexion. Il est donc de faire tout ce que l'on veut.

Pour l'activer il suffit d'ajouter la ligne suivante dans votre fichier /etc/pam.d/common-session:

[...]
session    optional     pam_exec.so    commande
[...]

Remplacer commande par la commande à exécuter.

Plusieurs variables d'environnements sont spécialement définies:

$PAM_TYPE
$PAM_USER
$PAM_RUSER
$PAM_RHOST
$PAM_SERVICE
$PAM_TTY

Notification de connexion par email

Une des fonction classiques de ce module est d'avoir une notification par email lors d'une connexion. Pour cela il suffit de créer un script /usr/local/bin/send-mail-on-login.sh> qui : - ne prendra en compte que les ouvertures de nouvelles connexions - limitera à un nombre limité d'utilisateur (admin et root ici) - Envoi les information par mail à l'administrateur

#!/bin/sh
if ([ "$PAM_TYPE" != "open_session" ] ||
    ([ "$PAM_USER" != "root" ] &&
     [ "$PAM_USER" != "admin" ]))
then
    exit 0
else
    {
        echo "User: $PAM_USER"
        echo "Remote Host: $PAM_RHOST"
        echo "Service: $PAM_SERVICE"
        echo "TTY: $PAM_TTY"
        echo "Date: `date`"
        echo "Server: `uname -a`"
    } | mail -s "$PAM_SERVICE login on `hostname -s` for account $PAM_USER" root
fi
exit 0

Ne pas oublier de le rendre executable à l'aide de la commande suivante:

# chmod + x /usr/local/bin/send-mail-on-login.sh

et de modifier le fichier /etc/pam.d/common-session en accord:

[...]
session    optional     pam_exec.so    /usr/local/bin/send-mail-on-login.sh
[...]

Maintenant à chaque connexion de root ou admin, un email sera envoyer à l'administrateur. Par exemple pour une connexion d'admin en ssh :

User: admin
Remote Host: dslb-000-000-000-000.pools.arcor-ip.net
Service: sshd
TTY: ssh
Date: mercredi 22 juin 2011, 22:46:38 (UTC+0200)
Server: Linux test 2.6.32-5-amd64 #1 SMP Mon Mar 7 21:35:22 UTC 2011 x86_64 GNU/Linux

Source

Scripting avec pam_exec, notification de connexion

Activation désactivation du wifi avec OpenWRT

2011-06-14T00:00:00+02:00

Le routeur WRT54GL possede deux boutons: un bouton de réinitialisation et un bouton SecureEasySetup. Lors de l'installation d'OpenWRT c'est bouton ne servent à rien. Voici comment leur donner une utilité comme activer et désactiver le wifi.

Script d'activation/désactivation du wifi

Dans un premier nous allons créer un script qui permettent de changer l'état du wifi. C'est à dire l'activer s'il est éteint et l'inactiver dans le cas contraire.

Pour cela il suffit de créer le fichier /sbin/woggle (ou avec un autre nom). Contenant ceci:

#!/bin/sh

case "$(uci get wireless.@wifi-device[0].disabled)" in
   1) uci set wireless.@wifi-device[0].disabled=0
      wifi
      echo 1 > /proc/diag/led/ses_white
   ;;
   *) uci set wireless.@wifi-device[0].disabled=1
      wifi
      echo 0 > /proc/diag/led/ses_white
      echo 2 > /proc/diag/led/wlan
   ;;
esac

Le script commence par récupérer l'état du wifi (uci get wireless.@wifi-device[0].disabled). S'il est désactivé (égale à 1), il l'active et allume la LED du bouton SES. Dans le cas contraire il le désactive et éteint les LED du bouton SES et du wifi.

Il ne faut pas oublier de le rendre exécutable avec la commande:

# chmod +x /sbin/woggle

Pour changer l'état du wifi il suffit de lancer le script sur la ligne de commande:

root@openwrt:# /sbin/woggle

Lien avec le bouton SES

Maintenant que nous avons un script qui change l'état du wifi il suffit de le lier au bouton SES, pour qu'il soit exécuter chaque fois que ce bouton est pressé.

Pour cela cela se passe via la gestion des événements hotplug. Il faut créer un répertoir button dans le repertoire /etc/hotplug.d et créer ensuite un script nommer par exemple 01-radio-toggle, contenant ceci:

#!/bin/sh
if [ "$BUTTON" = "ses" ] && [ "$ACTION" = "pressed" ] ; then
  ( sleep 1; /sbin/woggle ) &
fi

Maintenant pour activer ou désactiver le wifi il suffit d'appuyer sur le bouton SES.

Sources

[[http://wiki.openwrt.org/doc/howto/wifitoggle|Wifi Toggle]]

Lenteur avec le driver ath9k et le noyau 2.6.38 en wifi 802.11n

2011-05-12T00:00:00+02:00

Le passage au noyau 2.6.38 a une conséquence fâcheuse pour les cartes wifi utilisant le module ath9k en 802.11n: une diminution drastique du débit. Voici comment y remédier temporairement. Ce problème ne semble pas apparaître lors de l'utilisation d'autre norme que le wifi 802.11n comme le 802.11g.

Il suffit de créer le fichier de configuration du module ath9k /etc/modprobe.d/ath9k.conf et y mettre la ligne suivante:

options ath9k nohwcrypt=1

Un rechargement du module ou un redémarage de l'ordinateur devrait résoudre le problème.

Sources

Installation d'un serveur SMTP avec Postfix

2011-01-20T00:00:00+01:00

Installation du serveur SMTP Postfix pour recevoir et envoyer des email sur un serveur.

Installation et configuration de base

# aptitude install postfix

Répondre aux question en accord avec la configuration. Les descriptions associées à chaque paramètre sont explicites. Par défault c'est le format mailbox qui est utilisé pour stocké les messages. Pour changer en Maildir il suffit d'ajouter la ligne suivante au fichier de configuration principal de postfix /etc/postfix/main.cf:

home_mailbox = Maildir/

Dans cet exemple les mails seront sauvegarder sous le format Maildir (c'est à dire un message par fichier) dans le dossier Maildir du répertoire personnel de l'utilisateur.

Sécurisation

Plusieurs astuces de configuration permettent de bloquer une partie messages non solicités via des règles simples à ajouter à son fichier /etc/postfix/main.cf:

Ne pas vérifier si l'utilisateur existe sur le système:

disable_vrfy_command = yes

N'accepter les messages entrant que d'un serveur s'autentifiant complètement:

smtpd_helo_required = yes

Restriction de receptions via analyse des informations de l'expéditeur:

smtpd_sender_restrictions =
    permit_mynetworks,            # Autorise les envois depuis le même domaine
    permit_sasl_authenticated,    # Autorise les envois si authentifié
    reject_non_fqdn_sender,       # Rejete si l'expéditeur ne fourni pas un nom completement qualifié
    reject_unknown_sender_domain, # Rejete si cela provient d'un nom de domaine inconnue
    permit                        # Sinon autorise

Restriction sur le réseau d'envoie du mail

smtp_client_restrictions =
    permit_mynetworks,                                # Autorise les envois depuis le même domaine
    reject_rbl_client blackholes.easynet.nl,          # Différentes Blacklists
    reject_rbl_client cbl.abuseat.org,
    reject_rbl_client proxies.blackholes.wirehub.net,
    reject_rbl_client bl.spamcop.net,
    reject_rbl_client sbl.spamhaus.org,
    reject_rbl_client dnsbl.njabl.org,
    reject_rbl_client list.dsbl.org,
    permit

Un redémarage du service postfix est nécessaire pour prendre en compte la nouvelle configuration:

# service postfix restart

Manipulation de fichiers po

2011-01-17T00:00:00+01:00

Les fichiers po sont utilisés par les programmes afin de traduire les messages dans différentes langues. Ainsi ils contiennent une liste de toutes les chaînes traduisibles extraites du code, et la traduction qui correspond pour une langue donnée. Ici sont données quelques informations pour les manipuler ainsi que quelques ressources d'aide à la traduction, principalement extraites d'expériences issues du Projet de traduction Debian et plus particulièrement de l'équipe francophone.

File formating

Pour faciliter la lectures des fichiers textes sur tout type d'écran il est usuel de limiter la taille de leur ligne à 80 caractères. Pur les fichier po la commande suivante permet ainsi de couper les lignes à 80 caractères tout en conservant le marquage spécifique de ces fichiers:

$ msgcat fr.po -o fr.po

Il est possible de spécifier la longueur de la ligne à une autre valeur si nécessaire avec l'option -w. Ainsi pour formater un fichier po pour limiter les lignes à 40 caractères :

$ msgcat -w40 fr.po -o fr.po

Update of a file while already start the translation

Lors des traductions il arrive que le fichier po d'origine ai été mise à jour alors que votre traduction n'est pas fini. La commande suivanre permet de mettre à jour votre fichier po (fr.po) avec les nouvelles données issue du nouveau fichier po (fr.new.po):

$ msgmerge --update --previous fr.po fr.new.po

Vous pouvez ainsi continuer votre traduction sur le fichier fr.po mise à jour.

Ressources

Général

Base de données de propositions de traduction, construite à partir des traduction des projets libre: http://open-tran.eu/

Spécifiques à Debian (Equipe de traduction française)

Informations

Status and coordination

Fournir des dépôts Mercurial à travers lighttpd

2010-05-07T00:00:00+02:00

Voici comment publier un ensemble de dépôt Mercurial sur un serveur et pouvoir y accéder via CGI et donc un navigateur web classique. Une fois le dépôt installer il est très facile d'y créer de nouveaux dépôts.

Pré-requis

un serveur web fonctionnel (ici nous nous baseront sur lighttpd) voir [[linux:debian:webserveur]] pour son installation sur Debian.
une installation de Mercurial classique
le script hgwebdir.cgi ou hgwebdir.fcgi inclus avec votre version de Mercurial. Dans une installation Debian il est situé dans le dossier /usr/share/doc/mercurial/examples/. Il est également disponible à sur le site de Mercurial : hgwebdir.cgi
Dans le cas de l'utilisation de la version fastCGI du script (hgwebdir.fcgi) il faut également installer le module python flup (python-flup pour Debian)

Préparation du dépôt

Nous supposerons que le dépôt Mercurial sera situé dans le dossier /var/hg. Nous allons dans un premier temps créer la structure du dépôt :

# mkdir -p /var/hg/repos
# chown -R www-data:www-data /var/hg

Nous allons ensuite créer le fichier de configuration du dépôt /var/hg/hgweb.config qui nous permettra de prendre en compte les différents dépôts contenus dans le sous répertoire repos ():

[collections]
repos/ = repos/

Ensuite il faut placer le script hgwebdir.fcgi (dans le cas d'une utilisation de FastCGI) ou hgwebdir.cgi (dans le cas d'une utilisation de CGI) et de le rendre exécutable par le serveur web :

# mkdir /var/hg
# cp hgwebdir.fcgi /var/hg
# chown -R www-data:www-data /var/hg
# chmod +x /var/hg/hgwebdir.fcgi

Configuration de lighttpd

Dans un sous répertoire du site

Suivant la configuration de lighttpd, il faut éditer le fichier de configuration /etc/lighttpd/lighttpd.conf ou alors un fichier qui sera inclus lors du lancement de lighttpd (50-hg.conf). Sous Debian il suffit de créer un fichier dans le dossier /etc/lighttpd/available-conf/ et de faire un lien vers ce fichier dans /etc/lighttpd/enable-conf/. Dans un premier il faut inclure les modules nécessaires :

1  server.modules += ( "mod_cgi" )
2  server.modules += ( "mod_rewrite" )

Dans un second temps, il faut configurer la réécriture des adresses afin que les accès aux sous répertoire hg ou mercurial pour utiliser hgwebdir.fcgi :

3  url.rewrite-once = (
4    "^/hg([/?].*)?$" => "/hgwebdir.fcgi$1",
5     "^/mercurial([/?].*)?$" => "/hgwebdir.fcgi$1"
6  )

Enfin passer les paramètres au scripts cgi:

 7  $HTTP["url"] =~ "^/hgwebdir.fcgi([/?].*)?$" {
 8               server.document-root = "/var/hg/"
 9               cgi.assign = ( ".fcgi" => "/usr/bin/python" )
10  }

Dans un hôte virtuel

Dans ce cas les dépôts seront accessible directement à la racine de l'hôte va une adresse du type hg.example.com.

1  $HTTP["host"] == "hg.example.com" {
2      server.document-root = "/var/hg/"
3      cgi.assign = ( ".fcgi" => "/usr/bin/python" )
4  }

Dans ce cas les adresses afficheront le nom du script utilisé à savoir hgwebdir.fcgi. Il est possible rendre les adresses plus esthétiques en enlevant cette portion. Pour cela dans la configuration de l'hôte il suffit d'ajouter ne règle de réécriture :

url.rewrite-once = (
    "^(/hgwebdir.fcgi/.*)$" => "$1", "^(/.*)$" => "/hgwebdir.fcgi$1"
)

Il faut également modifier le fichier hgweb.config pour que les adresses générées ne possèdent plus le nom du script:

[web]
baseurl =

Limitation des push

Afin de pouvoir limiter les push à certaines personnes il faut modifier deux fichiers de configurations. Tout d'abord le fichiers de configuration du dépôt lui même (.hg/hgrc). Dans la section web il faut ajouter le nom des utilisateurs que l'on veut autoriser, ou alors une étoile (''*'') pour autoriser tout le monde:

[web]
allow_push = moimeme

Enfin pour lighttpd il faut rajouter les lignes suivantes dans le fichiers gérant l'authentification:

$HTTP["querystring"] =~ "cmd=unbundle" {
                auth.require = (   "" => (
                        "method"  => "basic",
                        "realm"   => "Mercuial Repo",
                        "require" => "valid-user"
                        )
                )
        }

Lors des push il se peut que cela echou avec l'erreur suivante:

ssl required

pour autoriser les push sans ssl il faut l'activer dans le fichier de configuration du dépôt dans la section web (.hg/hgrc) :

[web]
push_ssl = false

Sources

Publishing Repositories with hgwebdir.cgi

abort: requirement 'fncache' not supported!

2010-04-01T00:00:00+02:00

Il peut arriver que lors de l'accès à un dépôt Mercurial d'avoir l'erreur suivante :

abort: requirement 'fncache' not supported!

Cela arrive lors de l'utilisation d'une version "trop ancienne" de Mercurial. En effet, à partir de la version 1.1, Mercurial utilise un nouveau format de dépôt (fncache), qui n'est pas lisible par les versions antérieures. Par contre les anciens dépôts restent lisibles par ces nouvelles versions. Pour y remédier il faut convertir ce format de dépôt via la commande suivante en utilisant un Mercurial postérieur à 1.1 :

hg --config format.usefncache=0 clone --pull A B

Avec A le dépôt initial et B le dépôt converti.

Pour désactivé ce format de dépôt pour toutes nouvelles créations de dépôt, il suffit d'ajouter dans le fichier de configuration (~/.hgrc) :

[format]
usefncache = False

Sources

fncacheRepoFormat

Fusion de dépots sans aucun rapport (mercurial abort: repository is unrelated)

2010-04-01T00:00:00+02:00

Lorsque l'on essaye d'inclure un dépôt dans un autre alors qu'ils n'ont jamais rien eu en commun on obtient l'erreur suivante:

$ hg push ../second
mercurial abort: repository is unrelated

Pour passer outre il suffit de forcer la fusion avec l'option -f:

$ hg push -f ../second

Sources

hg man page

Nouvelle installation d'un serveur

2010-03-10T00:00:00+01:00

Une petite procedure pour configurer/améliorer un serveur fraichement installé sous Debian.

Configuration de base

Configuration des locales

Pour installer les locales sur le système: celles qui seront disponibles pour les utilisateurs.

# dpkg-reconfigure locales

Sélectionnez les locales en fonction des langues que vous voullez et les différent encodage de charactères. Plus vous sélectionnerez de langue et d'encodage plus cela prendra de temps à générer et plus cela occupera d'espace disque.

Par exemple pour obtenir les message en français séléctionnez les locales commençant par fr_FR (français de France) et tout les encodages. Le meilleur encodage pour Unix est UTF-8. Sur le second écran choisissez la langue et l'encodage par défaut qui sera utilisé par le système par exemple fr.FR.UTF-8, pour avoir les messages en français par défaut.

Configuration de bash

La création d'un nouvel utilisateur utilise les fichiers de configuration par défaut qui sont présents dans le dossier /etc/skel/. Cependant, par défaut l'utilisateur root n'obteint pas ces fichiers. Pour obtenir une meilleure configuration du shell bash pour root avec par exemple un prompt en couleur et l'autocomplétion nous allons copier manuellement .bashrc :

# cp /etc/skel/.bashrc $HOME

Ainsi l'auto-complétion de bash marche.

Pour avoir la couleur du prompt il faut décommenter la ligne 39.

39  #force_color_prompt=yes

et obtenir:

39  force_color_prompt=yes

On peut également décommenter dans les lignes 78 et suivantes les configuration de couleur pour quelques commandes

78  if [ -x /usr/bin/dircolors ]; then
79      test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval "$(dircolors -b)"
80      alias ls='ls --color=auto'
81      alias dir='dir --color=auto'
82      alias vdir='vdir --color=auto'
83 
84      alias grep='grep --color=auto'
85      alias fgrep='fgrep --color=auto'
86      alias egrep='egrep --color=auto'
87  fi

Configurer les alias pour le compte root

Par défaut tous les mails système sont envoyés à l'utilisateur root. Cependant, pour éviter des connexion intempestive de root, il est de bonne augure de rediriger les emails vers un autre compte ou adresse. Pour cela il suffit de modifier le fichier /etc/aliases pour qu'il contienne la ligne suivante:

root: nom@domain.com

Tous les emails envoyés à root seront redirigés vers l'adresse nom@domain.com

Sécurisation du système

Mise à jour du système

# aptitude update
# aptitude dist-upgrade

Pour recevoir automatiquement les annonce de mise à jour du système il faut installer le paquet apticron:

# aptitude install apticron

Les possible mises à jour du système seront envoyé par mail à root tous les jours.

Installation de fail2ban

fail2ban est un programme qui permet de blacklister temporairement une adresse IP lorsqu'elle est utilisée pour tenter de rentrer sur le site "en force" c'est à dire en essayant des mots de passe jusqu'à trouver le bon. En pratique fail2ban scrute les fichier de log et après un certain nombre d'échec de connexion, l'adresse IP est blacklister

# aptitude install fail2ban

Il se configure dans le fichier /etc/fail2ban/fail.conf. Quelques modules supplémentaires existent pour fail2ban pour les activer il faut se reporter à la fin du fichier de configuration (à partir de la ligne 74). Chaque module est appelé un JAIL.

Chaque JAIL se présente de façon similaire comme par exemple ssh:

[ssh]
enabled = true
port    = ssh
filter  = sshd
logpath  = /var/log/auth.log
maxretry = 6

Son nom entre [], s'il est activé ou nom (enable). Quel port fail2ban doit surveiller (port). Le fichier de log à surveiller (logpath) et le filtre à appliquer pour n'obtenir que le service voulu (filter). Et enfin le nombre d'erreurs toléré (maxretry).

Par défaut le JAIL ssh est activé. Le JAIL pam-generic permet de bloquer via l'identification d'erreur via l'utilisation de PAM. Le JAIL ssh-ddos permet une protection contre une attaque de type défaut de service

Pour prendre en compte la nouvelle configuration il faut redémarrer le service à l'aide la commande suivante:

# service fail2ban restart

Installation de rkhunter

Il s'agit d'un programme qui recherche les rootkit en recherchant les modifications des principaux programmes par comparaison avec un état sain et des signatures ainsi que l'identification de rootkit déjà connus. Voir son installation et configuration sur la page dédiée: rkunter

Installation de debsecan

Vérifie les alertes de sécurités sur internet en rapport avec le système:

# aptitude install debsecan

Pour le configurer il suffit d'exécuter la commande suivante:

# dpkg-reconfigure debsecan

Lors de la configuration, sélectionner la bonne distribution. Les autres questions se comprennent facilement.

Site web de debsecan

Configuration du pare-feu avec ferm

Consultez l'article correspondant à propos de ferm

Limitation des connexions SSH

Ne pas désactivé la connexion du super-utilisateur sans la présence d'un autre compte: il serait alors impossible de se connecter au serveur

Création d'un utilisateur administrateur (admin dans notre exemple) qui pourra se connecter en root après désactivation de la connexion SSH pour root:

# adduser admin

Une fois configuré, la connexion SSH de root peut être désactivée dans le fichier /etc/ssh/sshd_config:

26  PermitRootLogin no

Redémarrez le serveur SSH pour le prendre ne compte.

# /etc/init.d/ssh restart

Limitation de la commande su à certains utilisateurs

Il est fortement conseillé de rester connecté avec une console en root tout au long de la configuration et de vérifier que tout marche bien avant de la fermée: en cas d'erreur il se peut que l'accés à un shell super-utilisateur soit impossible.

La commande su permet de se substitué à un autre utilisateur pour exécuter certain programme. L'exemple le plus courant et le passage en super-utilisateur pour effectué des taches d'administration. Cependant il peut être bon de limiter l'accès à cette commande à certains utilisateurs. Par défaut su est donc lisible et exécutable par tout le monde. Cependant il est possible de restreindre à un groupe la connexion en modifiant le fichier de configuration PAM de su. Il faut décommenter la ligne suivante dans le fichier /etc/pam.d/su:

15  auth       required   pam_wheel.so

Par défaut il faut appartenir au groupe root pour pouvoir utiliser su. Historiquement ce groupe de super-utilisateur sur UNIX porte le nom de wheel d'où le nom du module PAM (voir [[wp>Wheel_(Unix_term)]]). Il est possible de changer le groupe d'utilisateur correspondant à wheel en ajoutant l'option group=nom_group. Ainsi pour définir le groupe adm comme le groupe wheel:

15  auth       required   pam_wheel.so group=adm

Il suffit d'ajouter ensuite les utilisateurs autorisé au groupe root, comme par exemple l'utilisateur admin:

# adduser admin root

Sources

bdb_equality_candidates: (uid) not indexed

2010-03-09T00:00:00+01:00

Il arrive que dans les fichier journaux (syslog) des messages comme suivant apparaissent:

Mar  9 14:56:13 kimsufi slapd[2187]: <= bdb_equality_candidates: (uid) not indexed
Mar  9 14:59:20 kimsufi slapd[23640]: <= bdb_equality_candidates: (gidNumber) not indexed

Comme le dit le message il s'agit d'erreur parce que certains attributs ne sont pas indexés. Pour les indexer, il suffit de le demander à OpenLDAP en modifiant le fichier /etc/ldap/slapd.conf pour ajouter les index manquant:

index ou,cn,sn,uid  pres,sub,eq
index uidNumber,gidNumber,memberUid     eq,pres

Dans un second temps il faut construire ces index. Pour ceci il convient dans un premier temps d'arréter le service OpenLDAP:

# /etc/init.d/slapd stop

De génerer les index avec la commande slapdindex:

# slapindex
  WARNING!
  Runnig as root!
  There's a fair chance slapd will fail to start.
  Check file permissions!
  /etc/ldap/slapd.conf: line 128: rootdn is always granted unlimited privileges.
  /etc/ldap/slapd.conf: line 145: rootdn is always granted unlimited privileges.

Il convient ensuite de donner les droits à l'utilisateur openldap de lire et écrire les fichiers de la base:

# chown openldap:openldap /var/lib/ldap/*

Puis dans un dernier temps de redémaré le service OpenLDAP:

# /etc/init.d/slapd start

Les messages d'erreurs devraient disparaitres des fichiers de log. Si d'autres index manquent, les rajouter en fonction.

Sources

OpenLDAP-SambaPDC-OrgInfo-Posix

Installation d'un dépôt subversion

2010-02-11T00:00:00+01:00

Installation de subversion

# apt-get install subversion subversion-tools

Accès distant au dépot via `svnserve`

svnserve est un serveur inclut dans subversion. Aucun paquet supplémentaire n'est necessaire. Ajout d'un utilisateur svn pour lancer svnserve

# adduser svn --system

Les dépôts seront stockés dans le dossier /home/svn/.

Pour permettre l'accès au dépôt il faut démarrer le serveur svnserve. Pour cela le petit script svn suivant placé dans /etc/init.d va permettre de le démarer comme n'importe quel autre serveur.

 1  #!/bin/sh
 2  # /etc/init.d/svn: set up the svnserve server
 3  ### BEGIN INIT INFO
 4  # Provides:          svn
 5  # Required-Start:    $local_fs
 6  # Required-Stop:     $local_fs
 7  # Should-Start:      $named
 8  # Should-Stop:       $named
 9  # Default-Start:     S
10  # Default-Stop:
11  ### END INIT INFO
12 
13  set -e
14 
15  PATH=/bin:/usr/bin:/sbin:/usr/sbin
16  SOCKET_DIR=/tmp/.X11-unix
17  ICE_DIR=/tmp/.ICE-unix
18 
19  . /lib/lsb/init-functions
20  . /etc/default/rcS
21 
22  case "$1" in
23  start)
24        log_daemon_msg "Starting svnserve daemon" "svnserve"
25        start-stop-daemon --start --quiet --background --pidfile /var/run/svnserve.pid --make-pidfile --exec \
26        /usr/bin/svnserve -c svn:svn -- -d --listen-port 3690 -r /home/svn
27        log_end_msg $?
28        ;;
29  stop)
30        log_daemon_msg "Stopping svnserve daemon" "svnserve"
31        killall svnserve
32        log_end_msg $?
33        rm -f /var/run/svnserve.pid
34        ;;
35 
36  *)
37        echo "Usage: /etc/init.d/rsync {start|stop}"
38        exit 1
39        ;;
40  esac
41  exit 0

Pour arrêter le serveur la commande start-stop-daemon --stop --quiet --oknodo --pidfile /var/run/svnserve.pid aurait du suffir, cependant il y a une petite erreur lors de la création du fichier pid de l'application ce qui ne permet pas d'arrêter svnserve.

Le fichier /etc/init.d/svn doit être executable.

# chmod +x /etc/init.d/svn

Pour démarer svnserve:

# service svn start

Ajout d'un dépôt

La commande svnadmin permet d'administrer les dépôts subversion.

# cd /home/svn
# svnadmin create nouveau_depot
# chown -R svn:svn nouveau_depot

Configuration du dépôt pour svnserve

Le fichier /home/svn/nouveau_depot/conf/svnserve.conf permet de configurer les options d'accès du dépôts via SVNserve.

[general]
anon-access = read
auth-access = write
password-db = passwd
realm = Mon dépôt SVN

Les autorisation de lecture/écriture sur le dépôt sont définies via les variables anon-access pour les utilisateurs non authentifiés et auth-access pour les utilisateurs authentifiés. Trois valeurs peuvent être utilisées:

none: aucun accès .
read: accès en lecture seule
write: accès en lecture/écriture

L'option realm permet de spécifier un nom pour le dépôt et l'option password-db de spécifier où seront stockées les logins et mots de passe des utilisateurs.

Le fichier password ressemble à ceci:

[users]
login = mot_de_passe
login = mot_de_passe
login = mot_de_passe

Sources

howto:svnserve

Comment organiser le code sources des "templates"

2010-02-11T00:00:00+01:00

En C et C++ il est habituel de séparer la déclaration d'une fonction et sa définition dans deux fichier séparés: l'entête contenant la déclaration (fichier .h ou .hh) et le code source proprement dit contenant sa définition (fichier .c ou .cpp). Lorsque l'on veut faire la même chose avec une fonction utilisant un template, on obtient une erreur du type "undefined reference to" lors de la première utilisation de la fonction dans le code.

Un exemple

Par exemple supposons la fonction addition qui retourne la somme de deux nombre de même type:

Tout d'abord le fichier d'entete (addition.hh):

template<typename Type> Type addition(Type a, Type b);

Le code source de la fonction (addition.cc):

template<typename Type> Type addition(Type a, Type b)
{
    return a + b;
}

Une portion de code utilisant cette fonction (main.cc):

#include "addition.hh"
void main()
{
    int a = 3;
    int b = 2;
    int c =0;
    c = addition(a, b)
}

Bien que le code semble correct, la création de lien va échouer avec l'erreur:

/tmp/ccEpROXj.o(.text+0x17c): In function `main':
: undefined reference to `addition(int, int)'

Le pourquoi

Il y a différentes raisons pour lesquels cette erreur apparait. Il s'agit principalement du fait qu'un template n'est pas une fonction mais un modèle utilisé pour générer la fonction. Lorsqu'il est utilisé dans un programme pour générer une fonction, la définition dois être connue et non seulement la déclaration.

Comment s'en sortir

Il existe plusieurs solutions à ce problème.

Insertion de la définition dans le fichier d'entête

La première consiste à inclure la définition dans le fichier d'entête. Pour cela il suffit de fusionner les deux fichiers entête et code source dans un seul fichier ou alors inclure le fichier du code source via une commande include de preprocessing à la fin du fichier d'entête. Cette solution est la plus simple mais le résultat n'est pas forcément très propre. En effet certains compilateur peuvent entrainer une augmentation dramatique de la taille de l'exécutable.

Ajout d'une spécialisation du template

FIXME: A confirmer

On peut également ajouter les déclaration des spécialisations que l'on veut utiliser dans le fichier source de la fonction.

Par exemple en reprenant le fichier source de notre fonction addition, on spécifier les déclarations pour les types int, float et double:

template<typename Type>
Type addition(Type a, Type b)
{
    return a + b;
}

template int addition<int>(int, int);
template float addition<float>(float, float);
template double addition<double>(double, double);

Utilisation du mot clef `export`

FIXME

Sources

Subversion déconnecter avec SVK

2010-02-11T00:00:00+01:00

Installation de SVK

apt-get install svk

Création d'un dépôt local via la commande:

svk depotmap --init

Créer un miroir local

svk mirror svn://adresse_du_depot_distant.ex //local/nom_local_du_depot
svk sync //local/nom_local_du_depot

Création d'une copie de travail à partir du dépôt local

svk checkout //local/nom_local_du_depot repertoire

Utilisation de SVK en local

Ajout de fichiers/dossiers à versionner

svk add fichier

Commit vers le dépôt locale

svk commit

Envoie des modifications du dépôt local vers le dépôt distant:

svk push

Sources

SVK par les Mongueurs de Perl

C++ links

2010-09-09T00:00:00+02:00

Installation d'un serveur LDAP pour authentification

2009-06-23T00:00:00+02:00

Installation du serveur LDAP

# aptitude install slapd ldap-utils
# dpkg-reconfigure slapd

Suivre les recommandations

On crée ensuite la structure de l'annuaire pour accueillir les utilisateurs et les groupes. Pour cela on crée le fichier /tmp/base.ldif:

dn: ou=People,dc=mondomaine,dc=tld
ou: People
objectClass: top
objectClass: organizationalUnit

dn: ou=Group,dc=mondomaine,dc=tld
ou: Group
objectClass: top
objectClass: organizationalUnit

On l'importe ensuite dans l'annuaire:

# ldapadd -D 'cn=admin, dc=mondomaine, dc=tld' -c -x -W -f /tmp/base.ldif

Récupération des utilisateurs et groupes actuels

Pour cela on va utiliser une série de scripts permettant contenus dans le paquet migrationtools:

# aptitude install migrationtools

Éditer le fichier /etc/migrationtools/migrate_common.pl et suivre les recommandations de http://wiki.gcu.info/doku.php?id=linux:auth_ldap

Récupération des information d'utilisateur et de groupe du système dans un fichier LDIF permettant un import facile dans l'annuaire LDAP:

# cd /usr/share/migrationtools
# ./migrate_passwd.pl /etc/passwd | grep -v 'objectClass: account' > /tmp/passwd.ldif
# ./migrate_group.pl /etc/group /tmp/group.ldif

Les utilisateurs qui seront inclus dans l'annuaire sont enregistrés dans le fichier /tmp/passwd.ldif et les groupes dans /tmp/group.ldif.

Ajouter pour chaque utilisateur

objectClass: account

Avant les autres objectClass, sinon erreur lors de l'import du type:

ldap_add: Object class violation (65)
additional info: no structural object class provided

On ajoute ensuite les utilisateurs et groupes dans l'annuaire:

# ldapadd -D 'cn=admin, dc=mondomaine, dc=tld' -c -x -W -f /tmp/passwd.ldif
# ldapadd -D 'cn=admin, dc=mondomaine, dc=tld' -c -x -W -f /tmp/group.ldif

Utilisateur en lecture de la base pour authentification

Éditer /etc/ldap/slapd.conf:

rootdn          "cn=admin,dc=mondomaine,dc=tld"

# service slapd restart

Création des information de l'utilisateur nss dans un nouveau fichier /tmp/nss.ldif:

dn: cn=nss,dc=mondomaine,dc=tld
objectClass: organizationalRole
objectClass: simpleSecurityObject
cn: nss
description: LDAP NSS user for user-lookups
userPassword:

Obtention du mot de passe:

slappasswd -h {CRYPT}

Ajout de l'utilisateur de lecture:

ldapadd -D 'cn=admin, dc=mondomaine, dc=tld' -c -x -W -f /tmp/nss.ldif

Installation de phpLDAPadmin pour lighttpd

2009-06-23T00:00:00+02:00

L'installation du serveur lighttpd avec PHP5 est nécessaire (voir Activation de PHP pour lighttpd)

# aptitude install phpldapadmin

Les scripts de phpLDAPadmin sont situés dans le dossier /usr/share/phpldapadmin. Pour y avoir accès il suffit de créer le fichier de configuration /etc/lighttpd/conf-available/50-phpldapadmin.conf:

# Alias for phpLDAPadmin directory
alias.url += (
        "/phpldapadmin" => "/usr/share/phpldapadmin",
)

# Disallow access to libraries
$HTTP["url"] =~ "^/phpldapadmin/lib" {
    url.access-deny = ( "" )
}

Enfin pour l'activer un simple lien dans le dossier /etc/lighttpd/conf-enable/ et un redémarrage du serveur web

# ln -s /etc/lighttpd/conf-available/50-phpldapadmin.conf /etc/lighttpd/conf-enabled/
# /etc/init.d/lighttpd restart

Sauvegarde et restauration d'un serveur LDAP

2009-06-23T00:00:00+02:00

Sauvegarde des données d'un serveur LDAP

Pour cela il suffit de sauvegarder la base dans un fichier LDIF. Le dump de la base LDAP s'effectue à l'aide de la commande slapcat:

# slapcat > base.ldif

Restauration des données d'un serveur LDAP

Pour charger le fichier dans le serveur il faut utiliser la commande slapadd:

# service slapd stop
# slapadd < base.ldif
# service slapd start

Le serveur de destination doit posséder un schéma de base lui permettant de prendre en charge les données du fichier sous peine d'un message d'erreur.

De même si des entrées existent déjà dans la base de destination, l'importation s'arrêtera.

Sécurisation des dossiers temporaires

2009-06-23T00:00:00+02:00

Le dossier /tmp est l'un des rares dossier du système qui soit accessible en écriture par tout le monde. Les utilisateur comme les services. Cependant beaucoup de vers utilisent des failles des application web pour déposer un fichier sur le serveur et arrive donc dans ce fameux dossier temporaire d'où le fichier peut être exécuter.

Afin de s'en prémunir il suffit de rendre le dossier temporaire non exécutable.

Monage du dossier `/tmp` en lecture/écriture seules

Pour inactivé l'exécution globalement dans un répertoire, il faut que cela concerne toute une partition. Il y a donc deux possibilité: soit le répertoire /tmp est déjà une partition à part soit il faut en crée une pour lui. Plutôt que de reformater complètement le disque pour créer cette partition, il est possible de transformer un fichier en partition loopback.

Pour cela il faut d'abord créer ce fichier comme dans l'article Création de fichier image disque et montage.

Pour monter le fichier automatiquement au démarrage il suffit d'ajouter la ligne suivante:

/fichier_temporaire /tmp ext3 loop,noexec,nosuid,nodev,rw 0 0

Où fichier_temporaire est le chemin complet vers le fichier contenant la partition destiné au répertoire temporaire. Les options noexec,nosuid,nodev permettent de bloquer l'exécution sur cette partition.

Dans le cas ou le dossier temporaire serait déjà sur une partition séparée, l'ajout des options noexec,nosuid,nodev pour l'entrée du fichier /etc/fstab correspondante permettra de bloquer l'exécution sur cette partition.

DPKG et erreur d'exécution

Lors de l'installation de paquets, les scripts de configurations sont placé dans le répertoire /tmp et exécutés. Cependant comme l'exécution est bloqué il ne peuvent pas se configurer renvoyant une erreur semblable à la suivante:

Can't exec "/tmp/quota.config.26141": Permission non accordée at /usr/share/perl/5.8/IPC/Open3.pm line 168

Lors de l'installation de paquets il faut donc rendre exécutable le répertoire temporaire via la commande suivante:

# mount -o remount,exec /tmp

Enfin, une fois les paquets installé la partition est de nouveau rendue non exécutable via la commande:

# mount -o remount,noexec /tmp

Il est possible de demander à dpkg de se débrouiller tout seul pour faire ce changement de permission sur le répertoire /tmp via un petit script de . Pour cela il suffit de modifier le fichier /etc/apt/apt.conf.d/70debconf pour qu'il ressemble à ceci:

//changement des permission d'exécution du répertoire /tmp
DPkg::Pre-Install-Pkgs {"mount -o remount,exec /tmp; /usr/sbin/dpkg-preconfigure --apt || true";};
DPkg::Post-Invoke {"mount -o remount,noexec /tmp";};

Une configuration analogue peut être effectuée avec le répertoire /var. Cependant vue la taille que ce répertoire peut atteindre lors de l'utilisation d'un serveur web il est conseillé d'utiliser une vraie partition et non un fichier loopback. Il faut également modifier le fichier /etc/apt/apt.conf.d/70debconf, dpkg utilisant le répertoire /var/cache/apt/ pour dépaqueter les paquets:

//changement des permission d'exécution du répertoire /tmp
DPkg::Pre-Install-Pkgs {"mount -o remount,exec /tmp; mount -o remount,exec /var; /usr/sbin/dpkg-preconfigure --apt || true";};
DPkg::Post-Invoke {"mount -o remount,noexec /tmp; mount -o remount,noexec /var;";};

Sources

Création de fichier image disque et montage

2009-06-22T00:00:00+02:00

Création d'une image disque de 1 Go à trou (utilisation réelle d'espace disque en fonction des besoins).

$ dd if=/dev/null of=image count=0 bs=1G seek=1

Formatage de l'image en ext3

$ /sbin/mkfs.ext3 -F image

Montage de l'image dans le répertoire loop/ (à adapter suivant le besoin) en tant que root

# mount image loop/ -o loop

rkhunter

2009-06-22T00:00:00+02:00

Pour chercher les rootkits présents sur le système et autre vers.

Installation

# aptitude install rkunter

La configuration à lieu dans le fichier /etc/rkhunter.conf. Par défaut certains tests sont inactivés comme par exemple hidden_procs qui a besoin du paquet unhide. Pour l'activer il suffit de l'enlever de la liste DISABLE_TESTS (ligne 199).

De même la vérification des paquet via le système de paquet est désactivé par défaut sur Debian puisqu'il met beaucoup de temps. Pour l'activer il faut activer l'option PKGMGR dans /etc/rkhunter.conf:

257 PKGMGR = DPKG

/proc/modules

Sur le serveur RPS d'OVH il n'y a pas le fichier /proc/modules ceci entraine un avertissement lors des test. Pour empêcher que cela apparaisse en permanence il suffit de désactivé ce test a l'aide de la variable DISABLE_TESTS auquel il faut ajouter la valeur os_specific dans /etc/rkhunter:

199 DISABLE_TEST="os_specific"

Message de la liste donnant la solution

Problème lors de la mise à jour de paquet

Lors de la mise à jour de paquets, certains fichiers peuvent être modifié et ne plus correspondre à ce que rkhunter avait détecté précédemment. Cela entraine donc des avertissements du style:

Warning: The file properties have changed:
         File: /sbin/syslogd
         Current inode: 563364    Stored inode: 563394

Pour mettre à jour la base de rkhunter concernant le suivi des modifications de fichier, il suffit de lancer la commande suivante:

rkhunter --propupd

Cela peut être automatisé à chaque installation de paquet via un script lancé par le système de paquet. Pour cela il suffit de créer le fichier /etc/apt/apt.conf.d/90rkhunter:

// Update rkhunter file signatures databases after running dpkg.
DPkg::Post-Invoke {
  "if [ -x /usr/bin/rkhunter ]; then if [ $(/usr/bin/rkhunter --help | /bin/grep "propupd" | /usr/bin/wc -l) -gt 0 ]; then /usr/bin/rkhunter --propupd; fi; fi";
};

Pare-feu facile avec ferm

2009-06-22T00:00:00+02:00

Il s'agit d'une interface simplifié à iptable, qui permet donc de configurer le pare-feu avec des règles plus lisible qu'iptable

Installation

# apt install ferm

Configuration

la configuration se situe dans le fichier /etc/ferm/ferm.conf. Par défaut, seul le port 22 est ouvert permettant les connexion ssh:

proto tcp dport ssh ACCEPT;

Pour ouvrir les port il suffit d'entrer des règles comparables. le port peut être spécifié soit via son numéro soit par le service qui lui est associé. Afin de déterminé quel service est associé à quel port il suffit de chercher les equivalences dans le fichier /etc/services

Sources

ferm - for Easy Rule Making

Démarrage parallèle avec insserv

2009-05-07T00:00:00+02:00

Par défaut les services des systèmes Linux démarrent les uns après les autres. Un moyen de gagner du temps lors du démarrage est de lancer les différent services en parallèle ce qui évite de devoir attendre qu'un service ait fini de démarrer pour en lancer d'autre.

Pour cela il faut modifier l'option CONCURRENCY dans le fichier /etc/init.d/rc. Par défaut elle est désactivée:

39  [...]
40  CONCURRENCY=none
41  [...]

Cette option peut prendre trois valeurs différentes:

none: désactivation de l'option de démarrage concurrentiel
startpar: les services sont lancés en parallèle mais leur sortie reste en série.
shell: les services sont lancés en parallèle dans des shell différents ainsi les sorties sont aussi parallélisées.

Plus la parallélisation augmente plus le temps de démarrage est raccourci.

Cependant certains services doivent être lancés après d'autre. Pour cela il faut réordonnancer les services pour être sur de ne pas démarrer un service tant que les pré-requis ne sont pas remplis. Par exemple le service de mise à jour de leur sur les serveur distant doit être lancé qu'une fois la connexion réseau établie.

Le paquet insserv permet de calculer les dépendances des différents scripts de démarrage, et ainsi de créer la hiérarchie nécessaire. Une fois installé il faut lancé la commande suivante en root pour optimiser les scripts init:

# update-bootsystem-insserv

Lors d'une mise à jour du système des messages d'avertissement similaire au suivant peuvent apparaitre:

insserv: warning: current start runlevel(s) (0 6) of script `umountroot' overwrites defaults (empty).

Cela veut simplement dire que l'ordre de lancement d'un ou plusieurs scripts init ont été modifiés lors de l'installation d'un ou plusieurs paquets. Il suffit de relancer la commande update-bootsystem-insserv pour refaire le calcul de hiérarchie t faire disparaitre ces messages d'avertissement.

Sources

Accélérer le boot de debian et ubuntu par Macsim

GPG et APT

2009-03-03T00:00:00+01:00

Comment ajouter une clé de chiffrement pour vérifier la signature des paquets d'un dépôt le système de gestion de paquets apt-get

Introduction

Une petite erreur du style :

W: GPG error: http://debian.ens-cachan.fr stable Release:
Les signatures suivantes n'ont pas pu être vérifiées car la clé publique n'est pas disponible : NO_PUBKEY 010908312D230C5F

Il s'agit d'une fonctionnalité du système d'apt-get permettant de garantir l'authenticité des serveurs de mise à jour Debian. Chaque paquets est signé à l'aide d'une clé de chiffrement. Avant sont installation la signature du paquet va être vérifiée en la comparant à celle obtenue localement. Pour y remédier il faut récupérer la clé de chiffrement.

Récupération de la clé en ligne de commande: apt-key

Dans un premier temps la clé va être récupérée sur un des serveurs de clés à l'aide de la commande suivante:

$ gpg --keyserver hkp://wwwkeys.eu.pgp.net --recv-keys 010908312D230C5F

Vous pouvez utiliser un autre serveur de clés. En principe ils se synchronisent entre eux. Remplacer l'identificant de la clé par celui demandé par le système apt-get.

Ensuite vous devez l’importer dans le système de paquetage apt-get à l’aide de la ligne suivante si vous utilisez sudo :

$ gpg --armor --export 010908312D230C5F | sudo apt-key add -

sinon en tant que super-utilisateur:

# gpg --armor --export 010908312D230C5F | apt-key add -

La clé peut être maintenant utiliser par le système de gestion de paquets.

Interface graphique du gestionnaire de clé pour apt-get: gui-apt-key

Il existe depuis quelque temps une interface graphique à apt-key : gui-apt-key. Pour le moment cette interface est uniquement disponible dans Etch. Vous pouvez l'installer à l'aide de votre gestionnaire de paquets préféré ou à l'aide de la commande suivante si vous utilisé sudo:

$ sudo apt-get install gui-apt-key

ou en temps que super-utilisateur:

# apt-get install gui-apt-key

L'interface est ensuite intuitive: recopiez l'indentifiant de la clé dans le champ "ID de la clé" et cliquez sur "Ajouter". Et la clé est ajoutée automatiquement.

Partage de fichier avec Network File System (NFS)

2009-03-02T00:00:00+01:00

Installation du serveur NFSv4

# apt-get install nfs-kernel-server nfs-common portmap

Les configurations s'effectue dans le fichier /etc/exports. La version 4 du protocole NFS permet de monter les répertoires partagés à partir d'une racine virtuelle. Il faut ajouter la ligne suivante au fichier /etc/exports pour que cette racine virtuelle soit /exports

/export       192.168.1.0/24(rw,fsid=0,insecure,no_subtree_check)

Configuration

Les sous répertoires du répertoire /exports seront donc partagés. Ainsi pour partager un nouveau répertoires il suffit de l'ajouter au répertoire /exports à l'aide de la commande suivante:

# mount --bind /home /exports/home

Afin que ce partage soit effectif à chaque démarrage du système il faut ajouter la ligne suivante dans le fichier /etc/fstab du serveur:

/home           /exports/home   none    rw,bind 0   0

Les règles de partage de ce répertoire se font de la même façon qu'avec la version 3 de NFS via l'édition du fichier /etc/exports. Chaque ligne commence par le chemin absolue du répertoire à partager suivie d'une liste des clients avec le détail de configuration.

/exports/home    192.168.1.0/24(rw,nohide,sync,insecure,root_squash,no_subtree_check)

Pour prendre en compte les différents points de montage il faut redémarrer le serveur NFS avec la commande suivante:

# /etc/init.d/nfs-kernel-server restart

Montage

Pour monter le système de fichier NFS sur le système de fichier du client il suffit d'utiliser la commande suivante qui va nous permettre de monter la totalité des répertoires exportés:

# mount -t nfs4 192.168.1.15:/ /media/nfs

Pour rendre ce montage définitif la ligne suivante doit être ajouter au fichier /ect/fstab de la machine cliente:

server:/home /home nfs4 rw 0 0

Sources

Setting up NFSv4

Configuration de carte wifi à base de chipset ISL38xx

2009-02-16T00:00:00+01:00

Pour ces cartes wifi, le driver Prism54 pour linux est nécessaire. Pour fonctionner un firmware doit être charger sur la carte wifi. Les modules Prism54 sont inclus dans le noyau linux, il suffit juste d'installer le firmware.

Le projet Prism54

Il existe plusieurs partie pour faire fonctionner la carte wifi:

islsm un driver linux supportant les cartes à base de ISL3886/ISL3887 (également connus sous le nom de cartes newmacs ou softmac).
FreeMAC un firmware sous licence GPL pour toute les cartes à base de puce Conexant.

Firmware

Les prérequis pour utiliser le driver sont un noyau 2.6 ainsi que hotplug. Le firmware à utiliser est à copier dans le repertoire /usr/lib/hotplug/firmware/. l'ensemble des firmware pour les différentes cartes sont disponibles sur le site du projet Prism54.

Dans le cas d'une clé USB de première génération il faut utilisé le driver 2.5.6.0 et le copié sous le nom isl3890usb.
Dans le cas d'une clé USB de deuxième génération il faut utilisé le driver 2.5.8.0 et le copié sous le nom isl3887usb.
Dans le cas d'une carte PCI ou PCMCIA il faut utilisé le driver 2.7.0.0 et le copié sous le nom isl3886.

En cas de doute il suffit de copier l'ensemble des firmwares, le driver choisira le bon lors de l'initialisation de la carte.

Sources

Donner un nom à une partition avec e2label

2009-02-16T00:00:00+01:00

Lors du montage des partitions le chemin d'accès au périphérique est généralement utilisé pour référencer une partition, à savoir cette ligne est présente dans votre fichier /etc/fstab:

# <file system> <mount point>    <type>  <options>       <dump>  <pass>
/dev/hda2       /mount/point     ext3    defaults         0       0

Ce style d'identification trouve ses limites lorsqu'il s'agit de périphérique amovible: il ne possède pas toujours le même nom. Il est possible d'attribuer une étiquette aux partition ext2/ext3 l'aide de l'utilitaire e2label. Ainsi la partition peut être retrouver via son étiquette.

Ajout d'une étiquette

Pour ajouter une étiquette à une partition, tapez la commande suivante en tant que root :

# e2label /dev/hdaX étiquette

hda correspond au périphérique (hda, hdb, sda, sdb, ...), X au numéro de partition, et étiquette à l'étiquette utilisée.

Référence dans /etc/fstab

Une fois l'étiquette alouée, le fichier /etc/fstab peut être modifié. Pour cela la référence au périférique devient LABEL=étiquette:

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
LABEL=etiquette /mount/point   ext3   defaults   0 0

Où etiquette est l'étiquette de la partition et /mount/point le répertoire où la partition doit être montée.

Jygraphe: Partage de gros fichiers personnel

2009-02-16T00:00:00+01:00

Installation

Récupérer l'archive de Jyraphe et la décompresser

$ wget http://download.gna.org/jyraphe/jyraphe-0.3.tar.gz
$ tar xvzf jyraphe-0.3.tar.gz

En tant que super-utilisateur déplacer dans un répertoire accessible par le serveur et changement de droit pour être éditable par le serveur.

# mv jyraphe-0.3/pub /var/www/jyraphe
# chown www-data:www-data /var/www/jyraphe/

Configuration

Lancer le script d'installation en allant à l'adresse http://votreserveur/jyraphe

Créez le dossier qui contiendra les fichiers à télécharger

mkdir /var/www/jyraphe/var-********

Empêchez l'écriture du fichier de configuration et supprimez le script d'installation

# chmod 500 /var/www/jyraphe/lib/config.local.php
# rm /var/www/jyraphe/install.php

Configuration de la taille maximal des fichiers

Réglez la taille maximal d'upload des fichiers en mofifiant le fichier php.ini. Pour la version CGI, /etc/php5/cgi/php.ini

; Maximum size of POST data that PHP will accept.
post_max_size = 100M

[...]

; Maximum allowed size for uploaded files.
upload_max_filesize = 100M

Redémarrez le serveur web pour prendre en compte le changement par exemple pour lighttpd:

/etc/init.d/lighttpd restart

Sources

site web de Jygraphe

Configuration du son d'une carte ATI azalia

2009-02-16T00:00:00+01:00

Ordinateur Dell Latitude D531, carte son ATI SBx00 azalia, debian Lenny: pas de son... Solution: la carte fonctionne avec des drivers ALSA pour Suse. Voici les étapes à suivre.

Télécharger les dernières versions

Il s'agit de télécharger les dernières versions d'alsa-lib, alsa-utils et alsa-driver:

(on suppose que ces fichiers ont été sauvegardés dans ~/downloads)

Copier ces fichiers dans les bons répertoires

Taper dans la console:

# mkdir -p /usr/src/alsa
# cd /usr/src/alsa
# cp ~/downloads/alsa* .
# tar xjf alsa-driver*.bz2
# tar xjf alsa-lib*.tar.bz2
# tar xjf alsa-utils*.tar.bz2

Remplacer les * par les noms exacts des fichiers téléchargés

Compiler et installer alsa-driver

# cd alsa-driver*
# ./configure --with-cards=hda-intel --with-kernel=/usr/src/linux-headers-$(uname -r)
# make
# make install

Compiler et installer alsa-lib

# cd ../alsa-lib*
# ./configure
# make
# make install

Compiler et installer alsa-utils

# cd ../alsa-utils*
# ./configure
# make
# make install

Enfin rebooter. Et au démarrage, le son est là!!

Sources

Sauvegarde de fichiers avec Rsync

2009-02-16T00:00:00+01:00

La sauvegarde de fichiers a toujours été un des points a ne pas négliger. Personne n'est à l'abri d'une défaillance qui entraîne une perte de données. Le logiciel Rsync permet de facilité cette tache. Nous allons voir ici comment le mettre en oeuvre.

Rsync

Rsync est un utilitaire open source qui permet de synchroniser des fichiers et répertoires entre deux endroits en minimisant le transfert de données. En effet Rsync ne transfert que la différence entre deux séries de fichiers.\ Il est téléchargeable sur le site officiel ou est accessible via le gestionnaire de paquet de votre distribution.

Sauvegarde dans un autre répertoire du même ordinateur

Rsync est un logiciel en ligne de commande et s'utilise simplement comme ceci:

rsync [OPTION] /repertoire/origine/ /repertoire/sauvegarde/

Remplacez bien entendu /repertoire/origine/ par le répertoire que vous voulez sauvegarder et ;code:/repertoire/sauvegarde/ par le répertoire ou sera stocké la copie de sauvegarde.

Les différentes options peuvent être obtenue via la page de manuel de Rsync (man Rsync). Nous allons voir les principales:

`-r, --recursive`	permet d'agir sur les différents sous-répertoires
`-l, --links`	copie les liens symboliques comme des liens symboliques
`-p, --perms`	conserve les permissions
`-t, --times`	conserve les dates de modification des fichiers
`-g, --group`	conserve le groupe du fichier
`-o, --owner`	conserve le propriétaire du fichier
`-a, --archive`	mode archive équivalent à -rlptgoD
`--delete`	supprime les fichiers du répertoire de destination quand ils sont absent du répertoire d'origine
`-v, --verbose`	mode verbeux: rsync dit tout ce qu'il fait

A l'aide de ces options vous pouvez facilement faire une copie de vos fichiers d'un répertoire vers un autre.

Sauvegarde incrémentale

Rsync vous permet de sauvegarder les fichiers modifiés ou supprimés. Vous obtenez cette action en utilisant l'option -b ou --backup. Par défaut le fichier modifié est renommé en y ajoutant un suffixe ~ ainsi le fichier exemple.txt sera sauvegarder en exemple.txt~. Vous pouvez changer ce suffixe via l'option --suffix=SUFFIX.

Les sauvegardes des fichiers peuvent être déplacés dans un autre répertoire que vous pouvez spécifier à l'aide l'option --backup-dir=DIR. Dans ce cas le suffixe n'est pas ajouté au fichier sauvegardé sauf si vous le précisez.A l'aide de cette dernière option et avec un petit script vous pouvez mettre en place une sauvegarde incrémentale. C'est à dire qu'à chaque sauvegarde de fichier modifié ou supprimé se fait dans un répertoire différent:

rsync -av --delete -b --backup-dir=/repertoire/sauvegarde/`date +%Y-%m-%d` \
    /repertoire/origine/ /repertoire/sauvegarde/

A chaque sauvegarde un répertoire de sauvegarde est créé dans /repertoire/sauvegarde/ de la forme annee-mois-jour.

Sauvegarde distante

Nous avons vu jusqu'à maintenant la sauvegarde dans un autre dossier du même ordinateur. Rsync permet également de faire des sauvegarde sur un ordinateur distant comme un serveur de sauvegarde par exemple. L'ordinateur distant doit avoir rsync installé pour que cela fonctionne. Pour cela il peut utiliser une connexion SSH:

rsync -av ssh /repertoire/origine utilisateur@serveur:/repertoire/sauvegarde/

Le mot de passe de l'utilisateur sera demandé comme pour toute connexion SSH.

Vous pouvez aussi mettre en place une connexion SSH sans mot de passe (par comparaison de clés) pour pouvoir automatiser la sauvegarde.

Blog

Installing a specific version of Bioconductor

Install a specific version of Bioconductor

Downgrade of already installed packages

Sources

Automatic deployment of pelican website with GitLab - The local way

Create a runner

General runner registration

Configuration of the mounted volume

Deployment

Configuration of the continuous integration

Sources

PHP activation for nginx

Configuration of PHP-FPM

Configuration of nginx

Sources

Two factor authentication

Installation of the PAM module

Activation for su

Activation for SSH server

Setting TOTP for an user

Source

Nginx as a proxy

Setup of the proxy for web traffic

Setup of the proxy for encrypted web traffic

Sources

Automatic deployment of pelican website with GitLab

Create a runner

Deployment

Setup of the private SSH key

Configuration of the continuous integration

Sources

Gitlab-runner installation

Installation of Docker

Install gitlab-ci-multi-runner

Create a runner

Easy firewall with ferm

Installation

Configuration

Sources

Executing a command at login

pam_exec

Email notification of a connexion

Source

LDAP authentication for lighttpd

Configuration of LDAP authentication

Configuration of folders to protect

Configuration activation

Sources

PHP activation for lighttpd

FastCGI configuration of PHP5

Configuration activation

Authentification via LDAP pour lighttpd

Configuration de l'authentification LDAP

Configuration des répertoires à protéger

Activation de la configuration

Sources

Activation de PHP pour lighttpd

Configuration de PHP5 en FastCGI

Activation de la configuration

tar and archives manipulation

Archives and their manipulation

General options

Creation

Extraction

Compressed archives

gzip compressed archives

Other compressions

Automatic detection of compression algorithm

tar et la manipulation d'archives

Les archives et leur manipulation

Options communes

Création

Extraction

Les archives compressées

Les archives compressées avec gzip

Les autres compressions

Détection automatique de l'algorithme de compression

Serving Mercurial repositories trough lighttpd

Pre-requirements

Activation for `su`

`gzip` compressed archives

Les archives compressées avec `gzip`

By using the `export` keyword.