How to block a package upgrade?Bloquer la mise à jour d’un paquet

Posted in Kubuntu, Lignes de commande, Linux and tagged 10.10, 11.04, apt-get, commandes, mise à niveau, unison on Oct 26, 2011

Coming soon…
Suite à la mise à jour de Kubuntu aux versions 10.10 puis 11.04 (voir ici et ici), je me suis retrouvée à réinstaller une ancienne version des paquets unison et unison-gtk. Ce tutoriel explique comment bloquer la mise à jour automatique de ce paquet.

Les lignes suivantes permettent de bloquer la mise à jour automatique des paquets unison et unison-gtk ;

echo "unison hold" | sudo dpkg --set-selections
echo "unison-gtk hold" | sudo dpkg --set-selections

Pour vérifier que le blocage est bien effectif, taper :

dpkg --get-selections | grep unison

qui doit retourner :

unison                    hold
unison-gtk              hold

Débloquer la mise à niveau est effectué par la commande suivante :

echo "unison install" | dpkg --set-selections
echo "unison-gtk install" | dpkg --set-selections

Installation pas à pas d’un serveur Ubuntu 10.04 : serveur git

Posted in Linux, Ubuntu serveur and tagged git, ssh on Oct 23, 2011

Ce tutoriel décrit comment installer un serveur git sur son serveur : git est un logiciel libre de gestion de versions décentralisée.

Attention ! Ce tutoriel a été écrit pour l’installation d’un serveur git avec gitosis ; dans les versions plus récentes de Ubuntu serveur (12.04 LTS par exemple), gitosis a été remplacé par gitolite, voir ce post (à la fin) pour plus de détails sur l’installation de gitolite, qui est assez similaire à celle de gitosis.

Initialisation de la configuration du serveur git

Dans un premier temps, on installe les packages nécessaires :

apt-get install git-core gitosis

En utilisant la clé ssh publique tuxette.pub permettant la connexion au server, initialiser le serveur git :

sudo -H -u gitosis gitosis-init < tuxette.pub

Le serveur répond :

Initialized empty Git repository in /srv/gitosis/repositories/gitosis-admin.git/
Reinitialized existing Git repository in /srv/gitosis/repositories/gitosis-admin.git/

Création d’un projet test

Sur votre ordinateur local, après avoir chargé votre clé privée (correspondant à la clé publique nath.pub), récupérer le dépôt administrateur de git

git clone gitosis@server.domain-name.org:gitosis-admin.git

où server.domain-name.org doit être remplacé par le nom de votre serveur.

Dans le répertoire gitosis-admin, éditer le fichier gitosis.conf qui est initialement de cette forme

[gitosis]

[group gitosis-admin]
writable = gitosis-admin
members = keyfilename

où keyfilename correspond au nom donné à votre clé (ne pas changer ce nom ni le fichier correspondant dans keydir sous peine de se voir banni du serveur. Ajouter un nouveau projet :

[gitosis]

[group team]
writable = testproject
members = keyfilename

[group gitosis-admin]
writable = gitosis-admin
members = keyfilename

puis mettre à jour les informations sur le dépôt admin de git :

git commit -a
git push

Sur votre ordinateur local, créez quelque part un répertoire testproject dans lequel vous placez un fichier test a_file.txt avant d’initialiser le dépôt git et de l’installer sur le serveur :

mkdir testproject
cd testproject
nano a_file.txt
git init
git add a_file.txt
git commit -a
git remote add origin gitosis@server.domain-name.org:testproject.git
git push origin master

Pour ajouter un nouvel utilisateur au projet testproject, de clé ssh publique tux.pub, placer le fichier tux.pub dans le répertoire gitosis-admin/keydir puis

git add keydir/tux.pub
git commit -a
git push

puis modifier le projet testproject dans le fichier gitconfig par :

[group team]
writable = testproject
members = keyfilename tux

(ne pas oublier de pousser les modifications sur le serveur).

Utilisation du dépôt git par l’utilisateur tux

Pour pouvoir récupérer le dépôt git, l’utilisateur tux doit posséder un client git

apt-get install git

pour ubuntu ou bien ce lien pour Mac OS X (voir ce post pour l’installation sur une version ancienne de Mac OS X) et ce lien pour Windows. Une fois installé, les commandes suivantes permettent d’initialiser la configuration :

git config --global user.name "Tux Dude"
git config --global user.email tux-email@whatnot.com

Enfin, pour configurer l’éditeur de test par défaut des messages de commit (j’utilise nano : basique mais rapide), utiliser la commande :

git config --global core.editor nano

Enfin, après avoir chargé sa clé privée, il peut récupérer le dépot git :

git clone gitosis@server.domain-name.org:testproject.git

En savoir plus : Plus d’information sur les manipulations de fichiers sur un dépôt git sur ce lien.

Installation pas à pas d’un serveur Ubuntu 10.04 : serveur mail

Posted in Linux, Mac OS X, Ubuntu serveur and tagged apple mail, ca-certificates, courrier électronique, cryptage, dovecot, fetchmail, postfix, postfix-mysql, roundcube, sécurité, ssl, thunderbird on Oct 23, 2011

Le cinquième post concerne l’installation et la configuration d’un serveur mail avec postfix, postfix-mysql, dovecot.

Tutoriel utile : http://workaround.org/ispmail/

Voir aussi ce post (installation de postfixadmin et utilisation via postfix) et ce post (mise à jour vers la version 12.04 du serveur mail en fin de post).

Installation de postfix et configuration de postfix-mysql
Configuration des certificats SSL pour postfix
Configuration du serveur IMAP avec dovecot
Configuration du SMTP distant
Configuration de fetchmail pour récupérer ses emails sur un autre serveur mail
Configuration du client pour envoyer/recevoir des emails depuis votre ordinateur personnel
Configuration du webmail roundcube

Installation de postfix et configuration de postfix-mysql

L’installation du serveur mail postfix se fait, en mode super utilisateur, via :

apt-get install postfix postfix-mysql

Lors de l’installation du serveur mail, il faut préciser le nom de domaine de votre serveur ; dans la suite nommé domain-name.org.

La deuxième étape de l’installation consiste à installer et créer la base de données du serveur mail qui contiendra les informations sur les utilisateurs et les noms de domaines du serveur. Sur MySQL (via PhpMyAdmin, par exemple),

créer une base de données nommée maildatabase ;
créer un utilisateur virtuel nommé mailuser avec les privilèges “select” sur la base de données maildatabase ;

trois tables doivent ensuite être créées sur la base de données maildatabase : domains pour les noms de domaine virtuels, users pour les utilisateurs virtuels et aliasespour lister les alias d’adresses. Le code SQL permettant la création de ces trois tables est donné ci-dessous :

CREATE TABLE `domains` (
     `domain_id` int(11) NOT NULL auto_increment,
     `domain_name` varchar(50) NOT NULL,
     PRIMARY KEY (`domain_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

CREATE TABLE `users` (
     `user_id` int(11) NOT NULL auto_increment,
    `d_id` int(11) NOT NULL,
    `passwd` varchar(32) NOT NULL,
    `user_email` varchar(100) NOT NULL,
    PRIMARY KEY (`user_id`),
    UNIQUE KEY `user_email` (`user_email`),
    FOREIGN KEY (d_id) REFERENCES domains(domain_id) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

CREATE TABLE `aliases` (
    `alias_id` int(11) NOT NULL auto_increment,
    `d_id` int(11) NOT NULL,
    `from` varchar(100) NOT NULL,
    `to` varchar(100) NOT NULL,
    PRIMARY KEY (`alias_id`),
    FOREIGN KEY (d_id) REFERENCES domains(domain_id) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

les informations concernant le serveur sont ensuite à insérer dans les tables correspondantes. Dans la suite, nous prenons l’exemple de deux domaines virtuels : serveur.domain-name.org et domain-name.org et deux deux utilisateurs tuxette@domain-name.org et tuxette@server.domain-name.org où tuxette@server.domain-name.org est un alias de tuxette@domain-name.org . Ces données sont insérées dans les tables correspondantes par les requêtes SQL suivantes :

INSERT INTO `maildatabase`.`domains` (
     `domain_id` ,
     `domain_name`
)
VALUES (
     '1' , 'server.domain-name.org'),(
     '2', 'domain-name.org'
);

INSERT INTO `maildatabase`.`users` (
     `user_id` ,
     `d_id` ,
     `passwd` ,
     `user_email`
)
VALUES (
     '1', '1', MD5('the-first-passwd'), 'tuxette@server.domain-name.org'
     '2', '2', MD5('the-second-passwd'), 'tuxette@domain-name.org'
);

INSERT INTO `maildatabase`.`aliases` (
     `alias_id` ,
     `d_id` ,
     `from` ,
     `to`
)
VALUES (
     '1', '1', 'tuxette@server.domain-name.org', 'tuxette@domain-name.org'
);

Il faut ensuite configurer le serveur postfix pour qu’il soit capable de lire ces informations : pour cela, créer un fichier /etc/postfix/mysql-virtual-domains.cfcontenant les informations suivantes :

user=mailuser
password=the-mailuser-passwd
hosts=127.0.0.1
dbname=maildatabase
query=SELECT 1 FROM domains WHERE domain_name='%s'

puis exécuter le script suivant (en super utilisateur) :

postconf -e virtual_mailbox_domains=mysql:/etc/postfix/mysql-virtual-domains.cf

Vérifier que tout fonctionne par :

postmap -q domain-name.org mysql:/etc/postfix/mysql-virtual-domains.cf

qui doit retourner la valeur “1”.
De même, créer les fichiers /etc/postfix/mysql-virtual-users.cf et /etc/postfix/mysql-virtual-aliases.cf contenant, respectivement,

user = mailuser
password = the-mailuser-passwd
hosts = 127.0.0.1
dbname = maildatabase
query = SELECT 1 FROM users WHERE user_email='%s'

user = mailuser
password = the-mailuser-passwd
hosts = 127.0.0.1
dbname = maildatabase
query = SELECT to FROM aliases WHERE from='%s'

puis exécuter les scripts :

postconf -e virtual_mailbox_maps=mysql:/etc/postfix/mysql-virtual-users.cf
postconf -e virtual_alias_maps=mysql:/etc/postfix/mysql-virtual-aliases.cf

Enfin, pour assurer que quelqu’un non autorisé n’aille lire ces fichiers, modifier les propriétaires et droits :

chgrp postfix /etc/postfix/mysql-*.cf
chmod u=rw,g=r,o= /etc/postfix/mysql-*.cf

Enfin, éditez le fichier /etc/postfix/main.cf et régler la taille maximale souhaitée pour les emails (en envoi et réception) :

message_size_limit = 10485760

(pour 10 Mo)

Configuration des certificats SSL pour postfix

Afin d’assurer le cryptage des données entre le serveur server.domain-name.org et le client (votre ordinateur personnel), des certificats de sécurité SSL sont mis en place. Ceux-ci sont générés comme décrit dans ce post et postfix est configuré pour utiliser ces certificats en exécutant les lignes de commande suivantes :

postconf -e "smtpd_tls_key_file = /etc/ssl/private/apache-enc-key.pem"
postconf -e "smtpd_tls_cert_file = /etc/ssl/certs/apache-cert.pem"
postconf -e "smtpd_tls_CAfile = /usr/share/ca-certificates/self/root-cacert.crt"
postconf -e "smtpd_tls_received_header = yes"
postconf -e "mydomain = domain-name.org"
postconf -e "myorigin = server.domain-name.org"
postconf -e "myhostname = server.domain-name.org"
postconf -e "mydestination = server.domain-name.org, localhost"

À ce stade, vous pouvez vérifier l’état de la configuration par :

/etc/init.d/postfix start

/etc/init.d/postfix reload

si postfix était déjà démarré. Le serveur doit démarrer sans erreur…

Configuration du serveur IMAP avec dovecot

Dovecot est installé par :

apt-get install dovecot-imapd

La configuration de dovecot est ensuite effectuée comme suit :

un groupe et un utilisateur mailusersont créés qui seront les seuls à avoir des droits sur les boîtes mail virtuelles (pour assurer la confidentialité des données :
```
groupadd -g 5000 mailuser
useradd -g mailuser -u 5000 mailuser -d /var/vmail -m
```
Le dossier dans lesquels les boîtes mail virtuelles seront stockées est ensuite créé (dans /home/mail) et les droits sur ces dossier sont donnés à l’utilisateur mailsuser:
```
mkdir /home/mail
chown -R mailuser:mailuser /home/mail
chmod 740 -R /home/mail
```
Le fichier /etc/dovecot/dovecot.confest édité pour
- assurer l’utilisation obligatoire de imaps (qui est la version sécurisée de imap). Pour cela, la ligne protocols = imap imaps est commentée et remplacée par la ligne protocols = imaps.
- préciser le dossier contenant les emails virtuels : mail_location = maildir:/home/mail/%d/%n/Maildir qui assure que les emails pour l’utilisateur tuxette@domain-name.org seront stockés dans le dossier /home/mail/domain-name.org/tuxette/Maildir
- configurer les certificats de sécurité pour imaps :
```
ssl_ca_file = /usr/share/ca-certificates/self/root-cacert.crt
ssl_cert_file = /etc/ssl/certs/dovecot-cert.pem
ssl_key_file = /etc/ssl/private/dovecot-enc-key.pem
ssl_verify_client_cert = no
verbose_ssl = yes
```
- autoriser dovecot à utiliser la base de données postfix en décommentant la ligne passdb sqlet en ajoutant
```
userdb static {
args = uid=5000 gid=5000 home=/home/mail/%d/%n/Maildir allow_all_users=yes
}
```
- permettre la communication entre dovecot et postfix en ajoutant les lignes suivantes :
```
socket listen {
master {
path = /var/run/dovecot/auth-master
mode = 0600
user = mailuser
}

client {
path = /var/spool/postfix/private/auth-client
mode = 0660
user = postfix
group = postfix
}
}

protocol lda {
auth_socket_path = /var/run/dovecot/auth-master
postmaster_address = tuxette@domain-name.com
log_path =
}
```
  Commenter également la partie « passdb pam » pour éviter les erreurs d’authentification pam (que l’on n’utilise pas) dans le fichier de log.</li> </ul> </li>
- Dovecot est ensuite configuré pour pouvoir utiliser la base de données MySQL : le fichier /etc/dovecot/dovecot-sql.confest édité de la manière suivante :
```
driver=mysql
connect = host=127.0.0.1 dbname=maildatabase user=mailuser
  password=the-mailuser-passwd
default_pass_scheme = PLAIN-MD5
password_query = SELECT user_email as user, user_passwd FROM users
  WHERE user_email='%u';
```
- Les derniers points de sécurité sont ajoutés en définissant les droits sur les fichiers de configuration de dovecot :
```
chgrp usermail /etc/dovecot/dovecot.conf
chmod g+r /etc/dovecot/dovecot.conf
chown root:root /etc/dovecot/dovecot-sql.conf
chmod go= /etc/dovecot/dovecot-sql.conf
```
- Dovecot et postfix sont ensuite respectivement configurés pour communiquer entre eux :
  - pour dovecot, le fichier /etc/dovecot/master.cfest édité et les lignes suivantes sont ajoutées :
```
dovecot unix - n n - - pipe
flags=DRhu user=usermail:usermail argv=/usr/lib/dovecot/deliver
  -f ${sender} -d ${recipient}
```
  - pour postfix, les lignes suivantes sont exécutées :
```
postconf -e virtual_transport=dovecot
postconf -e dovecot_destination_recipient_limit=1
```
  et la configuration est testée en relançant dovecot et postfix :
```
/etc/init.d/dovecot restart
/etc/init.d/postfix restart
```
  Pour tester la réception des emails et leur tri en local, on lance les commandes suivantes :
```
find /home/mail
echo test | mail tuxette@domain-name.org
find /home/mail
```
  la deuxième commande find doit faire apparaître la création du dossier mail virtuel pour l’utilisateur tuxette@domain-name.org dans lequel le message test a été stocké.</li>
- Si le test précédent est un succès, il est temps de rediriger les mails de votre nom de domaine domain-name.org vers votre serveur (à ce stade, OVH les redirige vers ses propres boîtes mail. Pour cela, se connecter à son manager OVH et cliquer sur “Domaines et champ DNS” ; dans la rubrique “Zone DNS” du domaine concerné, effacer les champs MX existants. Cliquer ensuite sur “Type A” et ajouter un champ comme ci-dessous :sous-domaine : domain-name.org sélectionner une IP : adresse_IP_du_serveur_de_mailCliquez sur “Validez” pour confirmer l’opération. Ensuite, choisissez “Type MX” et ajoutez un champ comme ci-dessous :Sous-domaine : domain-name.org Destination: mail2.domain-name.orgTester la réception d’emails depuis l’extérieur en envoyant un email à votre adresse (dans l’exemple tuxette@domain-name.org) et en exécutant à nouveau la commande
```
find /home/mail
```
  qui doit faire apparaître le nouvel email.</li>
- Un dernier test de lecture peut être pratiqué avec l’utilitaire mutt :
  - en local en lecture directe : mutt -f /home/mail/domain-name.org/tuxette/Maildir ;
  - en local en lecture imaps : mutt -f imaps://home/mail/domain-name.org/tuxette/Maildir qui doit demander la validation de 2 certificats de sécurité puis le mot de passe de l’utilisateur ;
  - à distance par imaps : mutt -f imaps://tuxette@domain-name.org@domain-name.org qui doit demander la validation de 2 certificats de sécurité puis le mot de passe de l’utilisateur.

Installation pas à pas d’un serveur Ubuntu 10.04 : Serveur Apache et SSL

Posted in Apache/PHP/MySQL, Linux, Ubuntu serveur and tagged apache, ca-certificates, cryptage, ssl, ubuntu on Jul 14, 2011

Le quatrième post concerne l’installation et la configuration d’un serveur apache, notamment pour sécuriser les échanges avec celui-ci via SSL.

Coming (probably not so) soon…

Installation de apache

Apache s’installe simplement par la commande

apt-get install apache2
/etc/init.d/apache2 start

L’installation est réussie si, lorsque vous tapez dans un navigateur votre nom de domaine (ou votre adresse IP), vous avez le message : “It works!”.

Les fichiers que vous voulez rendre accessibles depuis le serveur apache sont à placer dans le répertoire /var/www/ de votre serveur.

Configuration de apache pour la prise en charge des fichiers .htaccess

Si vous souhaitez restreindre l’accès d’un répertoire du type http://nom-du-serveur.org/dir/ par login et mot de passe, une méthode consiste à placer dans /var/www/dir un fichier nommé .htaccess et définissant les autorisations d’accès à ce répertoire. On procède de la manière suivante :

On édite le fichier /etc/apache2/sites-enabled/default et on y ajoute les lignes suivantes
```
    AllowOverride all
```
On relance ensuite le serveur apache :
```
/etc/init.d/apache2 reload
```
Dans le répertoire /var/www/dir, on crée un fichier nommé .htaccess et contenant les informations suivantes :
```
AuthUserFile /var/www/dir/password/.htpasswd
AuthGroupFile /dev/null
AuthName "Entrer login et mot de passe, svp"
AuthType Basic
Require valid-user
```
En l’état, ce fichier permet l’accès au répertoire /dir pour les utilisateurs identifiés par login et mot de passe, les logins et mots de passe étant inclus dans un fichier .htpasswd du sous-répertoire dir/password.
Dans le répertoire /var/www/dir/password, on crée deux fichiers :
- un fichier .htaccess contenant
```
deny from all
```
  qui interdit l’accès au répertoire password à tout le monde ;
- un fichier .htpasswd contenant
```
login1:enc-mdp1
login2:enc-mdp2
```
  où loginn sont les logins et enc-mdpn contient les mots de passe correspondant, préalablement encryptés (voir par exemple site web pour encrypter un mot de passe).

Configuration pour la prise en charge de SSL

SSL est un protocole qui permet des échanges sécurisés entre le serveur apache et le navigateur web. Pour mettre en place la sécurisation des échanges par SSL, il faut disposer d’un certificat qui est signé par une autorité. Généralement, pour les serveurs privés (qui ne prétendent pas faire de commerce, par exemple), un certificat SSL auto-signé suffit (l’utilisateur aura alors un message de sécurité lui indiquant que le certificat n’est pas signé par une autorité reconnue mais une fois l’exception de sécurité acceptée, les échanges se feront bien de manière sécurisée).

Les étapes suivantes décrivent :

comment générer un certificat d’autorité pour signer le certificat du serveur apache ;
comment générer et signer un certificat pour le serveur apache ;

comment configurer le serveur apache pour qu’il utilise SSL.

Création d’un fichier de configuration initial, root-cacert.cnf: ce fichier texte contient les informations suivantes :

# Configuration file example (root certificate)
# Default configuration to use when one is not provided on the command line.
[ ca ]
default_ca      = local_ca
# Default location of directories and files needed to generate certificates.
[ local_ca ]
dir             = /home/USERNAME/CertSSL
certificate     = $dir/root-cacert.pem
database        = $dir/index.txt
new_certs_dir   = $dir/signedcerts
private_key     = $dir/private/root-key.pem
serial          = $dir/serial
# Default expiration and encryption policies for certificates.
default_crl_days        = 365
default_days            = 1825
default_md              = md5
policy          = local_ca_policy
x509_extensions = local_ca_extensions
# Default policy to use when generating server certificates.  The following
# fields must be defined in the server certificate.
[ local_ca_policy ]
commonName              = supplied
stateOrProvinceName     = supplied
countryName             = supplied
emailAddress            = supplied
organizationName        = supplied
organizationalUnitName  = supplied
# x509 extensions to use when generating server certificates.
[ local_ca_extensions ]
subjectAltName          = DNS:server-name.org
subjectAltName          = DNS:*.server-name.org
basicConstraints        = CA:false
nsCertType              = server
# The default root certificate generation policy.
[ req ]
default_bits    = 2048
default_keyfile = /home//CertSSL/private/root-key.pem
default_md      = md5
prompt                  = no
distinguished_name      = root_ca_distinguished_name
x509_extensions         = root_ca_extensions
# Root Certificate Authority distinguished name.  Change these fields to match
# your local environment!
[ root_ca_distinguished_name ]
commonName              = Tuxette s Root Certificate Authority
stateOrProvinceName     = NC
countryName             = FR
emailAddress            = my-email@server-name.org
organizationName        = My Home
organizationalUnitName  = My Office
[ root_ca_extensions ]
basicConstraints        = CA:true

les parties [ local_ca ] et [ root_ca_distinguished_name ] sont à adapter à votre environnement de travail ; en particulier subjectAltName permettra de gérer des URL du type server-name.org et des sous-domaines du type subdomain.server-name.org. La partie default_days donne la durée de validité de votre certificat et elle est aussi à adapter à vos besoins éventuellement.</li>

Génération du certificat:

export OPENSSL_CONF=~/CertSSL/root-cacert.cnf
openssl req -x509 -newkey rsa:2048 -out root-cacert.pem -outform PEM -days 1825

un mot de passe à conserver précieusement vous est alors demandé.</li>

Nettoyage du certificat:

openssl x509 -in root-cacert.pem -out root-cacert.crt

un certificat SSL auto-signé pour le serveur, apache-cert.pem ;
une clé SSL pour le serveur, apache-enc-key.pem.

Création d’un fichier de configuration pour le certificat sur serveur, apache-cert.cnf:
```
# Configuration file example (server)
[ req ]
prompt                  = no
distinguished_name      = server_distinguished_name

[ server_distinguished_name ]
commonName              = server-name.org
stateOrProvinceName     = NC
countryName             = FR
emailAddress            = my-email@server-name.org
organizationName        = My Home
organizationalUnitName  = My Office
```
où la partie [ server_distinguished_name ] doit être personnalisée (particulièrement la partie commonName). Dans le cas où des sous-domaines sont utilisés sur le serveur, domain1.server-name.org et domain2.server-name.org, il faudra générer autant de certificats que de sous-domaines, chacun possédant une partie commonName personnalisée.</li>

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

export OPENSSL_CONF=~/CertSSL/apache-cert.cnf
openssl req -newkey rsa:1024 -keyout apache-key.pem -keyform PEM -out
  apache-temp-cert.pem -outform PEM

Un nouveau mot de passe vous est demandé, également à conserver précieusement.</li>

Encrypter la clé privée:
```
openssl rsa < apache-key.pem > apache-enc-key.pem
```
Le mot de passe entré précédemment est demandé.</li>
Signer le certificat du serveur avec le certificat d’autorité créé à la section précédente:
```
export OPENSSL_CONF=~/CertSSL/root-cacert.cnf
openssl ca -in apache-temp-cert.pem -out apache-cert.pem
```
Le mode de passe du certificat d’autorité est demandé.</li>
Supprimer les certificats temporaires inutiles
```
rm apache-temp-cert.pem apache-key.pem
```

Installation du certificat d’autorité sur le serveur : Créer un répertoire self dans /usr/share/ca-certificates et y déposer le fichier root-cacert.crt. Reconfigurer ca-certificatespour qu’il utilise ce certificat d’autorité :
```
dpkg-reconfigure ca-certificates
```
(cocher root-cacert de self dans la liste des certificats).</li>
Installation du certificat et de la clé du serveur : copier le fichier apache-cert.pem dans /etc/ssl/certs et le fichier apache-enc-key.pem dans /etc/ssl/private. Modifier les droits sur la clé privée :
```
chmod 400 /etc/ssl/private/apache-enc-key.pem
```
de manière à ce qu’elle ne soit pas lisible.</li>
Édition des fichiers de configuration du serveur apache : dans le répertoire, /etc/apache2/sites-available
- Éditer le fichier defaultde manière à ce qu’il commence par : < VirtualHost *:80>
```
        ServerAdmin my-email@server-name.org
        ServerName server-name.org
        ServerAlias www.server-name.org
```
  où les valeurs de ServerName et ServerAlias doivent correspondre à votre serveur.</li>
- Éditer le fichier default-sslde manière à ce qu’il commence par : < VirtualHost *:443>
```
        
        ServerAdmin my-email@server-name.org
        ServerName server-name.org
        ServerAlias www.server-name.org

        SSLEngine On
        SSLCertificateFile /etc/ssl/certs/apache-cert.pem
        SSLCertificateKeyFile /etc/ssl/private/apache-enc-key.pem
```
  où les valeurs de ServerName et ServerAlias doivent correspondre à votre serveur.</li> </ul> </li>
- Configuration de apache pour SSL
```
a2enmod ssl rewrite
a2ensite default-ssl
/etc/init.d/apache2 reload
```

Step-by-step Ubuntu server configuration: DNS and Reverse DNSInstallation pas à pas d’un serveur Ubuntu 10.04 : configurer le nom de domaine et le reverse DNS

Posted in Linux, Ubuntu serveur and tagged DNS on Jul 13, 2011

Coming soon …
Le troisième post concerne la paramétrisation du nom du serveur.

Le serveur est hébergé chez OVH chez lequel je possède aussi le nom de domaine (nathalievialaneix.eu). Les étapes permettant de changer le nom du serveur et d’y associer l’adresse IP sont les suivantes :

dans le manager OVH, sur l’interface de gestion du nom de domaine, faire pointer le nom de domaine vers l’adresse IP du serveur (dans Domaine & DNS -> Zone DNS, placer A du nom de domaine et des sous-domaines vers l’IP du serveur) ;
par connexion SSH, sur le serveur, tapez la commande
```
hostname machine.nom-du-domaine.org
```
pour un serveur nommé machine</coode> sur le nom de domaine<code>nom-du-domaine.org. Éditez ensuite le fichier /etc/hosts pour ajouter machine.nom-du-domaine.org machine en face de l'adresse IP puis redémarrez les interfaces réseaux :
```
/etc/init.d/networking restart
```
dans le manager OVH du serveur, configurer le DNS (dans Service -> Gestion DNS, associer le nom du serveur à l'adresse IP).

tuxette-chix

a girly blog about linux and free software

How to block a package upgrade?Bloquer la mise à jour d’un paquet

Installation pas à pas d’un serveur Ubuntu 10.04 : serveur git

Initialisation de la configuration du serveur git

Création d’un projet test

Utilisation du dépôt git par l’utilisateur tux

Installation pas à pas d’un serveur Ubuntu 10.04 : serveur mail

Installation de postfix et configuration de postfix-mysql

Configuration des certificats SSL pour postfix

Configuration du serveur IMAP avec dovecot

Configuration du SMTP distant

Configuration de fetchmail pour récupérer ses emails sur un autre serveur mail

Configuration du client pour envoyer/recevoir des emails depuis votre ordinateur personnel

Configurer thunderbird

Configurer apple mail

Configurer Outlook

Configuration du webmail roundcube

Installation pas à pas d’un serveur Ubuntu 10.04 : Serveur Apache et SSL

Installation de apache

Configuration de apache pour la prise en charge des fichiers .htaccess

Configuration pour la prise en charge de SSL

Step-by-step Ubuntu server configuration: DNS and Reverse DNSInstallation pas à pas d’un serveur Ubuntu 10.04 : configurer le nom de domaine et le reverse DNS

About Me

Copyright Notice

Recent Posts

Categories

Tags

Blogroll

Archives