Blog

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

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

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

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

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

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

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

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

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

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

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

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";
};

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

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

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

Blog

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

Serving Mercurial repositories trough lighttpd

Pre-requirements

Repository preparation

lighttpd configuration

In a sub-directory of the site

As a virtual host

Push limitation

Sources

Syncthing on server

Syncthing installation

Configuration for an user

First launch and connection to the interface

Configuration of Syncthing

Firewall

User setup for automatic start

Sources

Offline and caching of LDAP authentication

Sources

OpenVPN server on OpenWRT box

Installation of OpenVPN

Keys and certificates creation

Open the correct port in your firewall

Server configuration

Bridging of the interfaces

Client configuration

Source

RTSP through OpenWRT

Source

OpenWRT wifi toggle

Wifi toggle script

Link with the SES button

Sources

Activation for `su`

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

Monage du dossier `/tmp` en lecture/écriture seules