Systemd va pouvoir avoirune dépendance au réseau par exemple, pour monter le CIFS uniquement si la daemon réseau a bien été démarré. Le système pourra booter en level 3 même si le CIFS n’est pas joignable!

Le fichier systemd à placer dans /etc/systemd/system/

[Unit]
  Description=cifs mount script
  Requires=network-online.target
  After=network-online.service

[Mount]
  What=//192.168.56.1/mp$
  Where=/mnt/mp
  #Options=username=yourCifsUser,password=Secretpassword,workgroup=YourDomain,rw
  Options=credentials=/etc/systemd.cred.MonNas
  Type=cifs

[Install]
  WantedBy=multi-user.target

Je conseille d’utiliser le format avec un fichier de credentials qui aura des droits stricts 600 pour que seul root y accède. Laissant notre fichier systemd lisible.

• network-online permet d’attendre que la ressource réseau soit accessible avant de tenter le montage
• What est notre ressource distante
• where est notre point de montage local
• Options permet de définir les options, voir man mount.cifs
• Type est cifs dans ce cas-ci
• multi-user est le niveau 3 de démarrage, un classique

Le fichier credentials

username=MonUser
password=MonPass
domain=domain.tld

Nommage du fichier de configuration

Pour choisir un nom de fichier, attention que systemd est capricieux, il faut échapper pour être certain. Pour un répertoire, une option -p est prévue ainsi que --suffix.
Préféré un nom de point de montage avec des underscores plutôt que des tirets pour une meilleure lisibilité :

~$ systemd-escape -p --suffix=mount "/data/MON-DUMP-DB"
data-MON\x2dDUMP\x2dDB.mount
~$ systemd-escape -p --suffix=mount "/data/MON_DUMP_DB"
data-MON_DUMP_DB.mount

On relance et on active systemd :

sudo systemctl daemon-reload
sudo systemctl enable mnt-dp.mount
sudo systemctl start mnt-dp.mount

Quelques infos avec une variante pour un démontage après un temps d’inutilisation via automount.

Personnellement j’utilise ce montage pour faire les dump DB MySQL et mariaDB sur un NAS, afin de ne pas faire un backup d’une vm contenant elle-même des backups…

L’article Systemd – point de montage CIFS est apparu en premier sur Mon linux.

Cela est plus problématique lorsque vous utilisez les mêmes sites pour le professionnel que pour le personnel. Mon ancienne méthode était d’avoir 2 profils Firefox différents, mais il fallait également maintenir tout cela en parallèle…

On en vient aux Containers de Firefox…

L’article Gestion de profil sous Firefox – Les Containers est apparu en premier sur Mon linux.

Afin de stocker ses marques-pages ailleurs que dans le navigateur et penser à exporter souvent, on peut les stocker dans nextcloud via le plugin Bookmarks :

Une fois installé, l’application est disponible dans les raccourcis rapides :

Il faut maintenant installer un client sur votre navigateur. Dans mon cas ce sera Firefox mais la liste des modules tiers pour d’autres navitateurs sont présents sur la page gitbug du projet.

Firefox et Floccus

Il n’y a pas grand choix sous Firefox, soit floccus (freedommarks n’existant plus). Le premier permet d’avoir une synchronisation au contraire du second. C’est donc floccus que j’ai choisi. Actuellement, il y a à peine 2800 utilisateurs, mais le projet est assez nouveau.
Attention a bien désactiver la synchronisation de Firefox si vous l’aviez activée!

Après installation du module, on paramètre celui-ci :

On sélectionne la première option

Vous n’avez qu’à rentrer vos données pour vous connectez. Si vous avez une authentification 2FA comme moi, n’oubliez pas de créer un mot de passe applicatif pour cela

Folder mapping permet de synchroniser uniquement une sous arborescence de vos marques pages nextcloud, cela peut permettre d’avoir un « profil » perso et un profil de travail par exemple.
Dans mon cas je laisse la racine.
De bas la synchronisation se fait toutes les 15min, mais cela peut être changé dans Sync behavior.

Dans mon cas une première synchronisation n’a pas copier les marques-pages Firefox dans nextcloud sans avoir spécifié un dossier de destination. Sans doute un bug :

Ensuite on tente la synchro manuelle et nos bookmarks firefox sont bien dans nextcloud.

Erreur de synchronisation E020 sur Floccus sur le serveur Nextcloud

Si vous avez une erreur du type E020 : Impossible de lire la réponse du serveur. C’est probablement votre nextcloud qui renvoie une erreur 500.
Dans mon cas c’était à cause des emoji unicode que certains sites mettent dans leur titre et qui se sont retrouvé en titre de marque page…

Pour vous en assurer :

• taper dans la barre de Firefox : about:delugging
• Activez le debug globale :

• Utilisez le debugger :

• dans l’onglet réseau :

• lancez une synchronisation floccus (si besoin désactiver et réactiver le module)

• Vous verrez une erreur 500 avec toutes les infos nécessaires. Faites un clic droit > Copier > Copier comme cURL pour avoir la requête et la rejouer si besoin ou la partager dans le github
  

Si vous êtes dans le même cas, il faut activer le support 4-byte MySQL ou mariaDB pour résoudre le problème, ou bien supprimer les emoji de vos titres. C’est expliqué dans le Troubleshooting.

L’article Synchronisation sur Nextcloud de vos marques-pages Firefox est apparu en premier sur Mon linux.

Vous pouvez installer le contrôleur sur un serveur linux, windows ou macOS. C’est du java avec une base de données MongoDB. Il tourne très bien sur un serveur qui héberge aussi mon nextcloud, deluge, samba, etc. Mais mon « souci » est qu’il fonctionne sur un port alternatif et je voudrais le rendre disponible sur le port HTTPS où tourne déjà mon Apache avec nextcloud, un proxy pour deluge-web, let’s encrypt, etc.

L’accès à la gestion des clients et AP du contrôleur se fait via une page web principalement. Il existe aussi une application android. Il faut bien comprendre que sans contrôleur, on ne sait pas manager les AP. Donc ces AP ne disposent pas d’une page web d’administration comme les autres AP du marché grand public ou semi-pro.

L’application Android permet toutefois de faire un mode disvovery et faire une simple installation AP pour un seul réseau. Mais pour ce qui est de diffuser 2 SSID simultanés, de passer par un portail captif, etc. Il vous faut un contrôleur.

Pour lier un AP au contrôleur Unifi à distance, cela se fait soit via Unifi-discover sur pc (il faut être sur le même réseau ethernet layer2) ou via une app android Unifi. Les méthodes sont décrites sur la guideline d’Ubiquiti.

Je vous livre ma configuration d’Apache pour se connecter en HTTPS pour sécuriser l’accès à distance au contrôleur Unifi. Et ce sera avec une URL plus classe que http://unify.domain.com:8080/inform

Installer le paquet Unifi nécessaire

Vous pouvez récupérer le paquet le plus récent du software Unifi. Un paquet deb est dispo pour ceux qui sont sous Debian ou Ubuntu.

dpkg -i /disk/upload/unifi_sysvinit_all.deb
unifi depends on mongodb-server (>= 2.4.10) | mongodb-10gen (>= 2.4.14) | mongodb-org-server (>= 2.6.0); however:
Package mongodb-server is not installed.
Package mongodb-10gen is not installed.
Package mongodb-org-server is not installed.
unifi depends on openjdk-7-jre-headless | java8-runtime-headless; however:
Package openjdk-7-jre-headless is not installed.
Package java8-runtime-headless is not installed.
apt-get -f install

L’accès se fait via : https://localhost:8443
Attention que le premier réseau utilisable dans l’AP est en mode untagged

L’url pour joindre un second contrôleur : controller inform URL http://unify.domain.com:8080/inform

Mettre un proxy revers apache pour du WSS sur /wss et du http à la racine :

SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/unify.domain.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/unify.domain.com/privkey.pem

# Encoded slashes need to be allowed
AllowEncodedSlashes NoDecode

# Container uses a unique non-signed certificate
SSLProxyEngine On
SSLProxyVerify None
SSLProxyCheckPeerCN Off
SSLProxyCheckPeerName Off
# keep the host
ProxyPreserveHost On

# static html, js, images, etc. served from loolwsd
# loleaflet is the client part of LibreOffice Online
ProxyPass /wss wss://127.0.0.1:8443/wss retry=0
ProxyPassReverse /wss wss://127.0.0.1:8443/wss
ProxyPass / https://127.0.0.1:8443/ retry=0
ProxyPassReverse / https://127.0.0.1:8443/
ProxyPreserveHost On

L’accès au contrôleur Unifi se fait maintenant via https://unify.domain.com

L’article Configurer son contrôleur Ubiquiti UniFi dans son proxy Apache est apparu en premier sur Mon linux.

Il vous faut donc rapatrier toutes vos données avant la date butoir….

A compter de ce jour, vous ne serez plus habilité à commander de l’espace de stockage ou à renouveler des comptes existants. L’intégralité du service des comptes continuera jusqu’au 30 septembre 2015, date à laquelle tous les comptes actifs passeront en mode lecture seule. A compter du dimanche 15 novembre 2015, le service cloud de Wuala sera résilié.

Vous voilà donc prévenu.

Les détails se trouvent sur leur site, vraiment dommage ce service était pratique…

L’alternative proposée est Tresorit avec une offre partenaire qui revient à 7,50€ les 100Go qui propose également un chiffrement côté client.

L’article wuala – fin de l’aventure est apparu en premier sur Mon linux.

Je tiens à les remercier d’avoir accepté de mettre à ma disposition une machine pour ce test.

PlanetHoster plan 1

Détail de l’offre Medium :

• Virtualisation : KVM
• Processeurs : 1 vCore
• Mémoire : 1Go
• Espace disque 10 Go (SSD RAID10)
• ligne : 1000Mbps dont 100Mbps garanti
• SLA : 99,9%
• 1IPv4
• options proposées via leur service : consulter les statistiques, paramétrer les DNS secondaires, modifier le reverse DNS, installer un Rescue MX, lancer un scan de sécurité
• Prix : 19,99€HT/mois

Speedtest.py

Cela permet de tester la vitesse en upload et download de votre serveur linux.

Voici les commandes pour télécharger et exécuter le script python :

$ wget -O speedtest-cli https://raw.github.com/sivel/speedtest-cli/master/speedtest_cli.py
$ chmod +x speedtest-cli

$ ./speedtest-cli.py
Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from Groupe Barizco Inc. (185.22.109.12)...
Selecting best server based on latency...
Hosted by MEDIACTIVE NETWORK (Paris) [1.59 km]: 5.171 ms
Testing download speed........................................
Download: 266.57 Mbits/s
Testing upload speed..................................................
Upload: 202.66 Mbits/s

Le débit est impressionnant en trafic sortant : on atteint 33Mo/s en download mais surtout 25Mo/s en upload. La performance réseau est sans doute le point fort de ce type d’offre. On peut imaginer une plateforme d’échange de fichiers, mais il faudrait disposer de plus d’espace disque, ou connecter un backend comme Amazon EC2. La question étant, est-ce une ressource partagée ? Quelle ressource est garantie ? PlanetHoster assure que 100Mbps sont garantis et que le réseaux est en 1000Mbps.

Le temps de réponse du test est vraiment bon, seulement 5,2ms.

Téléchargement de fichier important

Le test est effectué avec un wget de plusieurs fichiers fourni comme moyen de test :

• fichier OVH France : wget http://proof.ovh.net/files/1Gio.dat
• fichier Thinkbroadband UK : wget http://download.thinkbroadband.com/1GB.zip
• fichier tweak.nl Pays-Bas : wget http://speedtest.tweak.nl/1000mb.bin

Voici les résultats pour Ikoula :

• fichier OVH France 1Go : 30,8 MB/s (4,5ms)
• fichier Thinkbroadband UK 1Go : 29 MB/s (10,5ms) (les temps de réponses sont assez fluctuants durant le test)
• fichier tweak.nl Pays-Bas 1Go : 24 MB/s (16,5ms)

Unixbench

Il permet de tester différents paramètres de votre serveur.

Pour l’installer vous aurez besoin de make et quelques autres paquets :

apt-get install libx11-dev libgl1-mesa-dev libxext-dev perl  perl-modules make gcc
cd /opt && wget https://byte-unixbench.googlecode.com/files/UnixBench5.1.3.tgz && tar -xzf UnixBench5.1.3.tgz
cd UnixBench
./Run

1 CPU in system; running 1 parallel copy of tests

Dhrystone 2 using register variables       39628251.9 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                     4839.3 MWIPS (4.9 s, 7 samples)
Execl Throughput                               6023.4 lps   (30.0 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks       1063931.5 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks          281688.9 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks       3339283.8 KBps  (30.0 s, 2 samples)
Pipe Throughput                             1869159.8 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                 356947.5 lps   (10.0 s, 7 samples)
Process Creation                               5673.4 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                   3635.3 lpm   (60.0 s, 2 samples)
Shell Scripts (8 concurrent)                    712.5 lpm   (60.0 s, 2 samples)
System Call Overhead                        2656592.3 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0   39628251.9   3395.7
Double-Precision Whetstone                       55.0       4839.3    879.9
Execl Throughput                                 43.0       6023.4   1400.8
File Copy 1024 bufsize 2000 maxblocks          3960.0    1063931.5   2686.7
File Copy 256 bufsize 500 maxblocks            1655.0     281688.9   1702.0
File Copy 4096 bufsize 8000 maxblocks          5800.0    3339283.8   5757.4
Pipe Throughput                               12440.0    1869159.8   1502.5
Pipe-based Context Switching                   4000.0     356947.5    892.4
Process Creation                                126.0       5673.4    450.3
Shell Scripts (1 concurrent)                     42.4       3635.3    857.4
Shell Scripts (8 concurrent)                      6.0        712.5   1187.4
System Call Overhead                          15000.0    2656592.3   1771.1
                                                                   ========
System Benchmarks Index Score                                        1490.2

Il présente un score acceptable, sans toutefois être impressionnant. Le score est 3x plus important qu’un Core i7 lancé sur un seul threads et représente 3/4 d’un Core i7 si les opérations sont lancés sur les 4 coeurs.

Processeur

Le test suivant est fait via la génération aléatoire udev, qui charge un coeur du processeur pour écrire un fichier de 100Mo de données aléatoires :

$ dd if=/dev/urandom of=/dev/null bs=1M count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 6.1173 s, 17.1 MB/s
$ dd if=/dev/urandom of=/dev/null bs=1M count=500
500+0 records in
500+0 records out
524288000 bytes (524 MB) copied, 28.7278 s, 18.3 MB/s

On atteint 17,1 Mo/s et le même est fait juste après pour un fichier de 500Mo pour atteindre 18,3 Mo/s. C’est un chiffre tout à fait honorable, c’est plus de 7 fois plus rapide que sur un core i7-2760QM 2,4Ghz. Cela devrait suffire à toutes vos applications, compte tenu du peu d’espace disque de cette offre. PlanetHoster assure qu’on dispose d’un coeur dédié de la machine physique (Dell R720, R920, etc).

Pour tester la compression via xz, gzip et pbzip2, il faut tenir en compte également la vitesse du disque. Le fichier utilisé pour le test est celui d’ovh (http://ovh.net/files/1Gio.dat) :

$ time cat 1Gio.dat | xz > 1Gio.dat.xz
real    6m21.558s
user    6m17.396s
sys     0m2.461s

$ time cat 1Gio.dat | gzip > 1Gio.dat.gz
real    0m34.563s
user    0m32.191s
sys     0m2.073s

$ time cat 1Gio.dat | pbzip2 -p2 -9 -c > 1Gio.dat.bz2

real    9m17.323s
user    9m9.242s
sys     0m6.220s

Les performances CPU se ressentent également lors de la compression. Au niveau compression Xz, il est aussi rapide d’un Core i7 (xz n’utilise qu’un seul thread). Pour la compression gzip et bzip on est respectivement à 5,6x et 2,1x plus rapide qu’un i7, ces valeurs sont vraiment très enthousiastes.

SysBench

Différents tests de benchmarkt sont possibles avec Sysbench : test CPU, test I/O, test de mémoire vive, etc.

Performance du CPU

Ce test est basé sur 1 seul thread (pour les VPS proposant 2vCores on travaillera avec 2 threads pour relativiser les résultats) :

# sysbench --test=cpu --num-threads=1 --cpu-max-prime=20000 run
sysbench 0.4.12:  multi-threaded system evaluation benchmark

Removing test files...
root@virtual684653:~# sysbench --test=cpu --num-threads=1 --cpu-max-prime=20000 run
sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1

Doing CPU performance benchmark

Threads started!
Done.

Maximum prime number checked in CPU test: 20000


Test execution summary:
    total time:                          24.1414s
    total number of events:              10000
    total time taken by event execution: 24.1406
    per-request statistics:
         min:                                  2.33ms
         avg:                                  2.41ms
         max:                                 22.99ms
         approx.  95 percentile:               2.39ms

Threads fairness:
    events (avg/stddev):           10000.0000/0.00
    execution time (avg/stddev):   24.1406/0.00

Il se défend remarquablement encore une fois : 16 fois plus rapide qu’un babana pi, et 2x moins d’un core i7-2760QM 2,4Ghz (test fait sur 2 threads…). Si le test sur i7 aurait été fait sur un seul threads, on serait sensiblement au même score qu’avec ce VPS.

Performances des I/O

Dans un premier temps on prépare des fichiers de tests. Il est mieux de mettre 10x plus que la RAM, mais on fait avec l’espace dont on dispose et un VPS n’en a pas beaucoup. Ici on dispose de 8,4Go d’espace libre sur les 10Go présent, on va donc faire avec.

$mkdir test
$cd test
$ sysbench --test=fileio --file-total-size=8G prepare
sysbench 0.4.12:  multi-threaded system evaluation benchmark

128 files, 65536Kb each, 8192Mb total
Creating files for the test...

$ sysbench --test=fileio --file-total-size=8G --file-test-mode=rndrw --init-rng=on --max-time=300 --max-requests=0 run
sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1
Initializing random number generator from timer.


Extra file open flags: 0
128 files, 64Mb each
8Gb total file size
Block size 16Kb
Number of random requests for random IO: 0
Read/Write ratio for combined random IO test: 1.50
Periodic FSYNC enabled, calling fsync() each 100 requests.
Calling fsync() at the end of test, Enabled.
Using synchronous I/O mode
Doing random r/w test
Threads started!
Time limit exceeded, exiting...
Done.

Operations performed:  2124415 Read, 1416276 Write, 4531968 Other = 8072659 Total
Read 32.416Gb  Written 21.611Gb  Total transferred 54.027Gb  (184.41Mb/sec)
11802.20 Requests/sec executed

Test execution summary:
    total time:                          300.0025s
    total number of events:              3540691
    total time taken by event execution: 85.9520
    per-request statistics:
         min:                                  0.01ms
         avg:                                  0.02ms
         max:                                 31.75ms
         approx.  95 percentile:               0.03ms

Threads fairness:
    events (avg/stddev):           3540691.0000/0.00
    execution time (avg/stddev):   85.9520/0.00

$ sysbench --test=fileio --file-total-size=8G cleanup

Sur la partie I/O rien à dire, on remarque directement que l’on est sur du SSD, on est 114x plus rapide que sur un disque dur USB relié au banana pi. Si vous cherchez un serveur pour héberger une application contenant principalement une base de données moyenne (limite des 10Go d’espace disque) avec beaucoup d’accès concurrents, c’est idéal. L’accès à la DB sera rapide.

Performance mémoire

Niveau performance mémoire, les valeurs importantes sont les 1329018 ops/sec et 1297.87 MB/sec.

$ sysbench --test=memory --memory-total-size=800M runsysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1

Doing memory operations speed test
Memory block size: 1K

Memory transfer size: 800M

Memory operations type: write
Memory scope type: global
Threads started!
Done.

Operations performed: 819200 (1329018.49 ops/sec)

800.00 MB transferred (1297.87 MB/sec)


Test execution summary:
    total time:                          0.6164s
    total number of events:              819200
    total time taken by event execution: 0.4948
    per-request statistics:
         min:                                  0.00ms
         avg:                                  0.00ms
         max:                                  0.42ms
         approx.  95 percentile:               0.00ms

Threads fairness:
    events (avg/stddev):           819200.0000/0.00
    execution time (avg/stddev):   0.4948/0.00

Les performances d’accès mémoire sont vraiment très bonnes. Elles sont 2,5x plus rapides que celles d’un core i7 avec DDR3. Concrètement dans le cas d’un VPS disposant d’1Go de RAM, ce critère ne doit pas être pris en compte dans votre choix. Ces performances sont bien plus importantes que celles nécessaires. Toutefois, si vous optez pour une offre disposant de plus de mémoire RAM, cela à un sens.

Lecture/Ecriture via dd

Voici le test effectué avec un fichier de 2Go, en écriture et lecture. Attention au cache disque pour la vitesse de lecture,

$ dd if=/dev/zero of=/root/zero bs=1M count=2000
2000+0 records in
2000+0 records out
2097152000 bytes (2.1 GB) copied, 2.73578 s, 767 MB/s
$ dd if=/root/zero of=/dev/null bs=1M 
2000+0 records in
2000+0 records out
2097152000 bytes (2.1 GB) copied, 0.725424 s, 2.9 GB/s

On atteint une vitesse très importante : 767 Mo/s en écriture et 2,9 Go/s en lecture (oui vous avez bien lu Go). Cela confirme l’utilité sans conteste de ce type de VPS pour des accès rapides aux données.

Apache local

Ceci est fait par un test de 1000 requêtes avec 30 connexions actives sur un Pydio 6.0.2. Pour plus de renseignement sur les options de AB, j’y ai consacré un article.

$ ab -n 1000 -c 30 http://server/pydio
Server Software:        Apache/2.2.22
Server Hostname:        localhost
Server Port:            80

Document Path:          /pydio
Document Length:        306 bytes

Concurrency Level:      30
Time taken for tests:   0.417 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Non-2xx responses:      1000
Total transferred:      552000 bytes
HTML transferred:       306000 bytes
Requests per second:    2396.16 [#/sec] (mean)
Time per request:       12.520 [ms] (mean)
Time per request:       0.417 [ms] (mean, across all concurrent requests)
Transfer rate:          1291.68 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   0.6      1       4
Processing:     3   11   1.0     11      13
Waiting:        1   10   0.9     10      11
Total:          5   12   0.7     12      16

Percentage of the requests served within a certain time (ms)
  50%     12
  66%     12
  75%     12
  80%     12
  90%     12
  95%     12
  98%     13
  99%     13
 100%     16 (longest request)

Les temps de réponse d’Apache sont tout à fait correcte.

Apache distant

Server Software:        Apache/2.2.22
Server Hostname:        185.22.109.12
Server Port:            80

Document Path:          /pydio
Document Length:        314 bytes

Concurrency Level:      30
Time taken for tests:   7.593 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Non-2xx responses:      1000
Total transferred:      564000 bytes
HTML transferred:       314000 bytes
Requests per second:    131.71 [#/sec] (mean)
Time per request:       227.780 [ms] (mean)
Time per request:       7.593 [ms] (mean, across all concurrent requests)
Transfer rate:          72.54 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       37   75 237.5     43    3041
Processing:    40  151 372.8     81    2342
Waiting:       40  151 372.7     81    2342
Total:         80  226 440.7    129    3221

Percentage of the requests served within a certain time (ms)
  50%    129
  66%    138
  75%    168
  80%    187
  90%    244
  95%    300
  98%   2323
  99%   2393
 100%   3221 (longest request)

Ces valeurs sont correctes également.

Conclusion

Leur serveur répond correctement, tout est vraiment très fluide, la console ne saccade jamais, ce qui permet de travailler correctement. Un gros bémol est l’image Debian proposée. On dispose d’une version Squeeze non mise à jour, et sans les dépôts LTS. Une version Wheezy serait plus que la bienvenue afin de ne pas devoir faire de dist-upgrade dès le départ. Il n’y a pas de dépôt interne, mais vu le débit réseau fourni, s’est inutile.

Si vous cherchez un serveur pour héberger une application contenant une base de données moyenne (limite des 10Go d’espace disque) avec beaucoup d’accès concurrents, ce serveur est fait pour vous. Vous aurez la rapidité d’accès à la DB et également la rapidité du processeur pour le frontend web ou java. Le service sera accessible sans goulot d’étranglement non plus sur la bande passante interne. Ce VPS est vraiment typé pour ce genre d’application.

Leurs performances sont bonnes, même très bonnes, et le prix s’en ressent. L’infrastructure proposée est plus importante que lors d’autres tests. Mais pour ce prix, je m’attendais franchement à disposer d’une image à jour du système installé. Ou tout du moins disposer d’une version Debian Wheezy, elle est sortie en mi 2013. Ce côté du service est aussi à prendre en compte lors de votre choix d’un VPS.

Les performances CPU sont très bonnes. Au niveau réseau et I/O rien à redire c’est les plus hauts scores jusqu’à présent. La stabilité, la rapidité et le temps de réponse sont au rendez-vous.

L’article [dossier] Comparatif des offres hosting VPS – PlanetHoster plan 1 est apparu en premier sur Mon linux.

Critères de tests des VPS

Je me base uniquement sur ces éléments pour mes tests, qui correspondent à mes besoins :

• Vitesse de download/upload via un script speedtest en python
• Vitesse de download sur de gros fichiers effectuée avec un wget de plusieurs fichiers fourni comme moyen de test
• Disponibilité (via un serveur qui va faire des ping de disponibilité via mon)
• Test d’apache via ab
• test global via unixbench
• test du processeur via compression gzip et xz, plus pour d’informations sur les comparaisons regardez cet article et via le fichier /dev/urandom
• Évaluation du processeur et des I/O via sysbench
• test de la vitesse disque via dd (dans openvz il n’est pas possible d’utiliser bonnie++)
• apréciation subjective de la réactivité du système (console)

Listes des offres testées

• VPS low cost
  • Firtheberg LP2 (1.99 € HTmois) : 2vcore, 2Go de RAM, 30 Go d’espace disque, OpenVZ, ligne 100Mbps
  • Prochainement ovh VPS classic 1 ( 1,99€HT/mois) : 1vcore, 1Go de RAM, 10Go d’espace disque, ligne 100Mbps
• VPS plus performants
  • Ikoula Flex’Servers NG 1CPU (12,99€HT/mois) : 1CPU Xeon, 1Go de RAM, 40Go d’espace disque, Hyper-V, ligne 100Mbps
    
  • PlanetHoster Plan 1 (19,99€HT/mois) : 1vCore, 1Go de RAM, 10Go d’espace disque, KVM, ligne N/A
  • Prochainement Firstheberg GP1 : (3,99€HT/mois) : 2vCore, 1Go de RAM, 50Go d’espace disque, KVM, ligne 100Mbps

Comparatif

Voici un récapitulatif des offres testées, qui sera complété au fur et à mesure et étoffé de quelques graphiques si le temps le permet :

• Réseau

• CPU

• I/O

L’article [dossier] Comparatif des offres hosting VPS low cost est apparu en premier sur Mon linux.

Je tiens à les remercier d’avoir accepté de mettre à ma disposition une machine pour ce test.

Ikoula Flex’Servers NG 1 CPU

Détail de l’offre Medium :

• Virtualisation : Hyper-V
• Processeurs : 1 CPU intel Xeon
• Mémoire : 1Go
• Espace disque 50 Go
• ligne : 100Mbps
• SLA : 99,9% ( Réseau / Garantie de connectivité)
• 1IPv4
• options proposées via leur interface : consulter les statistiques, paramétrer les DNS secondaires, modifier le reverse DNS, installer un Rescue MX, lancer un scan de sécurité
• Prix : 12,99€HT/mois

Speedtest.py

Cela permet de tester la vitesse en upload et download de votre serveur linux.

Voici les commandes pour télécharger et exécuter le script python :

$ wget -O speedtest-cli https://raw.github.com/sivel/speedtest-cli/master/speedtest_cli.py
$ chmod +x speedtest-cli

$ ./speedtest_cli.py
Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from Ikoula Net SAS (94.125.162.127)...
Selecting best server based on latency...
Hosted by Bouygues Telecom (Paris) [1.59 km]: 6.124 ms
Testing download speed........................................
Download: 184.44 Mbits/s
Testing upload speed..................................................
Upload: 49.87 Mbits/s

On voit déjà que la ligne présente un bon ratio download/upload. On est à 23Mo/s en download et 6,2Mo/s en upload. Ce qui est plus que satisfaisant pour une utilisation personnel, mais convient très bien pour une PME voulant disposer d’un espace d’échange de fichiers par exemple.

Le temps de réponse du test est plus que correcte.

Téléchargement de fichier important

Le test est effectué avec un wget de plusieurs fichiers fourni comme moyen de test :

• fichier OVH France : wget http://proof.ovh.net/files/1Gio.dat
• fichier Thinkbroadband UK : wget http://download.thinkbroadband.com/1GB.zip
• fichier tweak.nl Pays-Bas : wget http://speedtest.tweak.nl/1000mb.bin

Voici les résultats pour Ikoula :

• fichier OVH France 1Go : 6.2 MB/s (6,99ms)
• fichier Thinkbroadband UK 1Go : 5.98 MB/s (11ms)
• fichier tweak.nl Pays-Bas 1Go : 5.71 MB/s (18,5ms)

Unixbench

Il permet de tester différents paramètres de votre serveur.

Pour l’installer vous aurez besoin de make et quelques autres paquets :

apt-get install libx11-dev libgl1-mesa-dev libxext-dev perl  perl-modules make gcc
cd /opt && wget https://byte-unixbench.googlecode.com/files/UnixBench5.1.3.tgz && tar -xzf UnixBench5.1.3.tgz
cd UnixBench
./Run

1 CPU in system; running 1 parallel copy of tests

Dhrystone 2 using register variables       16572540.8 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                     2558.4 MWIPS (9.9 s, 7 samples)
Execl Throughput                               2462.5 lps   (29.9 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks        479691.8 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks          150111.8 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks       1082050.6 KBps  (30.0 s, 2 samples)
Pipe Throughput                             1127864.6 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                 213930.1 lps   (10.0 s, 7 samples)
Process Creation                               7628.7 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                   4153.6 lpm   (60.0 s, 2 samples)
Shell Scripts (8 concurrent)                    582.6 lpm   (60.0 s, 2 samples)
System Call Overhead                        2556591.4 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0   16572540.8   1420.1
Double-Precision Whetstone                       55.0       2558.4    465.2
Execl Throughput                                 43.0       2462.5    572.7
File Copy 1024 bufsize 2000 maxblocks          3960.0     479691.8   1211.3
File Copy 256 bufsize 500 maxblocks            1655.0     150111.8    907.0
File Copy 4096 bufsize 8000 maxblocks          5800.0    1082050.6   1865.6
Pipe Throughput                               12440.0    1127864.6    906.6
Pipe-based Context Switching                   4000.0     213930.1    534.8
Process Creation                                126.0       7628.7    605.5
Shell Scripts (1 concurrent)                     42.4       4153.6    979.6
Shell Scripts (8 concurrent)                      6.0        582.6    971.0
System Call Overhead                          15000.0    2556591.4   1704.4
                                                                   ========
System Benchmarks Index Score                                         920.3

Il présente un score acceptable, sans toutefois être impressionnant. Le score est 3x plus important qu’un Core i7 lancé sur un seul threads et représente 3/4 d’un Core i7 si les opérations sont lancés sur les 4 coeurs. Le descriptif de l’offre parle de vCore Xeon

Processeur

Le test suivant est fait via la génération aléatoire udev, qui charge un coeur du processeur pour écrire un fichier de 100Mo de données aléatoires :

$ dd if=/dev/urandom of=/dev/null bs=1M count=100
100+0 enregistrements lus
100+0 enregistrements écrits
104857600 octets (105 MB) copiés, 18,9761 s, 5,5 MB/s
$ dd if=/dev/urandom of=/dev/null bs=1M count=500
500+0 enregistrements lus
500+0 enregistrements écrits
524288000 octets (524 MB) copiés, 98,1086 s, 5,3 MB/s

On atteint 5.5 Mo/s et le même est fait juste après pour un fichier de 500Mo pour atteindre 5.3 Mo/s. C’est assez constant dans le temps, mais je m’attendais à un chiffre un peu plus élevé

Pour tester la compression via xz, gzip et pbzip2, il faut tenir en compte également la vitesse du disque. Le fichier utilisé pour le test est celui d’ovh (http://ovh.net/files/1Gio.dat) :

$ time cat 1Gio.dat | xz > 1Gio.dat.xz
real    12m59.066s
user    12m38.419s
sys     0m12.745s

$ time cat 1Gio.dat | gzip > 1Gio.dat.gz
real    1m25.238s
user    1m17.573s
sys     0m4.828s

$ time cat 1Gio.dat | pbzip2 -p2 -9 -c > 1Gio.dat.bz2

real    9m17.323s
user    9m9.242s
sys     0m6.220s

Au niveau compression Xz, il se défend très bien, tout en étant 2 fois plus lent qu’un Core i7 (xz n’utilise qu’un seul thread). Pour la compression gzip et bzip rien à redire, ces valeurs sont bonnes.

SysBench

Différents tests de benchmarkt sont possibles avec Sysbench : test CPU, test I/O, test de mémoire vive, etc.

Performance du CPU

Ce test est basé sur 1 seul thread (pour les VPS proposant 2vCores on travaillera avec 2 threads pour relativiser les résultats) :

# sysbench --test=cpu --num-threads=1 --cpu-max-prime=20000 run
sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1

Doing CPU performance benchmark

Threads started!
Done.

Maximum prime number checked in CPU test: 20000


Test execution summary:
    total time:                          43.2052s
    total number of events:              10000
    total time taken by event execution: 43.1905
    per-request statistics:
         min:                                  2.90ms
         avg:                                  4.32ms
         max:                                 32.82ms
         approx.  95 percentile:               6.33ms

Threads fairness:
    events (avg/stddev):           10000.0000/0.00
    execution time (avg/stddev):   43.1905/0.00

Il se défend très bien, 10 fois plus rapide qu’un babana pi, mais 4x moins d’un core i7-2760QM 2,4Ghz (test fait sur 2 threads…).

Performances des I/O

Dans un premier temps on prépare des fichiers de tests. Il est mieux de mettre 10x plus que la RAM, mais on fait avec l’espace qu’on a et un vps n’en a pas beaucoup, on essaye donc de partir sur 15Go. Ici Ikoula propose 2 parties dans son offre de 50Go :

• 10Go pour le système (9Go pour la racine, 500Mo pour tmp et 500Mo pour /var/tmp)
• 40Go pour /data

Nous allons voir la différence entre ces 2 espaces de stockage. Je pense que les data seront dans un SAS moins performant que la partie système.

$mkdir test
$cd test
$ sysbench --test=fileio --file-total-size=7G prepare
sysbench 0.4.12:  multi-threaded system evaluation benchmark

128 files, 57344Kb each, 7168Mb total
Creating files for the test...

$ sysbench --test=fileio --file-total-size=7G --file-test-mode=rndrw --init-rng=on --max-time=300 --max-requests=0 run
Running the test with following options:
Number of threads: 1
Initializing random number generator from timer.


Extra file open flags: 0
128 files, 56Mb each
7Gb total file size
Block size 16Kb
Number of random requests for random IO: 0
Read/Write ratio for combined random IO test: 1.50
Periodic FSYNC enabled, calling fsync() each 100 requests.
Calling fsync() at the end of test, Enabled.
Using synchronous I/O mode
Doing random r/w test
Threads started!
Time limit exceeded, exiting...
Done.

Operations performed:  31560 Read, 21040 Write, 67253 Other = 119853 Total
Read 493.12Mb  Written 328.75Mb  Total transferred 821.88Mb  (2.7396Mb/sec)
  175.33 Requests/sec executed

Test execution summary:
    total time:                          300.0024s
    total number of events:              52600
    total time taken by event execution: 257.0355
    per-request statistics:
         min:                                  0.01ms
         avg:                                  4.89ms
         max:                                181.35ms
         approx.  95 percentile:              18.45ms

Threads fairness:
    events (avg/stddev):           52600.0000/0.00
    execution time (avg/stddev):   257.0355/0.00

$ sysbench --test=fileio --file-total-size=7G cleanup

$ cd /data
$ sysbench --test=fileio --file-total-size=15G prepare
sysbench 0.4.12:  multi-threaded system evaluation benchmark

128 files, 122880Kb each, 15360Mb total
Creating files for the test...
root@80476hpv162127:/data# sysbench --test=fileio --file-total-size=15G --file-test-mode=rndrw --init-rng=on --max-time=300 --max-requests=0 run
sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1
Initializing random number generator from timer.


Extra file open flags: 0
128 files, 120Mb each
15Gb total file size
Block size 16Kb
Number of random requests for random IO: 0
Read/Write ratio for combined random IO test: 1.50
Periodic FSYNC enabled, calling fsync() each 100 requests.
Calling fsync() at the end of test, Enabled.
Using synchronous I/O mode
Doing random r/w test
Threads started!
Time limit exceeded, exiting...
Done.

Operations performed:  51601 Read, 34400 Write, 110080 Other = 196081 Total
Read 806.27Mb  Written 537.5Mb  Total transferred 1.3123Gb  (4.4791Mb/sec)
  286.67 Requests/sec executed

Test execution summary:
    total time:                          300.0046s
    total number of events:              86001
    total time taken by event execution: 247.3312
    per-request statistics:
         min:                                  0.01ms
         avg:                                  2.88ms
         max:                                195.32ms
         approx.  95 percentile:              13.14ms

Threads fairness:
    events (avg/stddev):           86001.0000/0.

Sur la partie système, nous avons en lecture 493.12Mb et 328.75Mb en écriture (2,74Mb/sec). C’est 70% plus rapide qu’un disque dur USB relié au banana pi. Cela sera suffisant pour la plupart des applications, mais pas forcement pour une base de données importante.

Pour la partie data, contrairement à ce que je m’attendais, les performances sont meilleures ; 806,27Mb en lecture et 537,5Mb en écriture (4,48Mb/sec), presque 3 fois plus rapide qu’un disque dur USB relié au banana pi cette fois. Si vous comptez mettre un service utilisant beaucoup d’I/O, je vous conseille de mettre les données dans /data ; quitte à créer quelques liens symboliques afin de gagner en performance.

Performance mémoire

Niveau performance mémoire, les valeurs importantes sont les 225383 ops/sec et 220.10 MB/sec.

$ sysbench --test=memory --memory-total-size=800M run
sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1

Doing memory operations speed test
Memory block size: 1K

Memory transfer size: 800M

Memory operations type: write
Memory scope type: global
Threads started!
Done.

Operations performed: 819200 (225383.66 ops/sec)

800.00 MB transferred (220.10 MB/sec)


Test execution summary:
    total time:                          3.6347s
    total number of events:              819200
    total time taken by event execution: 2.8060
    per-request statistics:
         min:                                  0.00ms
         avg:                                  0.00ms
         max:                                 10.72ms
         approx.  95 percentile:               0.00ms

Threads fairness:
    events (avg/stddev):           819200.0000/0.00
    execution time (avg/stddev):   2.8060/0.00

Les performances d’accès mémoire sont médiocres, elles sont de moitié moins que celle d’un core i7 avec DDR3. Mais concrètement, cela n’a pas d’impact dans ce cas-ci. Avec nos 1Go de RAM, on ne va pas pouvoir faire tourner des services gourmands en mémoire de toute façon. C’est donc adapté au service proposé.

Lecture/Ecriture via dd

Voici le test effectué avec un fichier de 2Go, en écriture et lecture. Attention au cache disque pour la vitesse de lecture,

$ dd if=/dev/zero of=/root/zero bs=1M count=2000 ; sleep 60 ; dd if=/dev/zero of=/data/zero bs=1M count=2000
2000+0 enregistrements lus
2000+0 enregistrements écrits
2097152000 octets (2,1 GB) copiés, 4,04273 s, 519 MB/s
2000+0 enregistrements lus
2000+0 enregistrements écrits
2097152000 octets (2,1 GB) copiés, 6,00628 s, 349 MB/s
$ dd if=/root/zero of=/dev/null bs=1M ; sleep 60 ; dd if=/data/zero of=/dev/null bs=1M

On atteint une vitesse importante pour le système  519 Mo/s en écriture et 198 Mo/s en lecture. Pour data, on obtient 349 Mo/s en écriture et 250 Mo/s en lecture. Ce qui est très remarquable pour un VPS de ce type.

Ces résultats sont contradictoires avec les tests de sysbench. Ils montrent ici qu’à court terme (10 secondes), la partition racine est plus rapide que celle des data. Les disques systèmes sont peut-être dans un SAN équipé en SSD pour le cache. Ceci serait une explication à cette incohérence.

Mais quoi qu’il en soit, les performances sont vraiment au rendez-vous sur ce point, on est sur une infrastructure qui répond aux besoins.

Apache local

Ceci est fait par un test de 1000 requêtes avec 30 connexions actives sur un Pydio 6.0.2. Pour plus de renseignement sur les options de AB, j’y ai consacré un article.

$ ab -n 1000 -c 30 http://server/pydio
Server Software:        Apache/2.2.22
Server Hostname:        94.125.162.127
Server Port:            80

Document Path:          /pydio
Document Length:        316 bytes

Concurrency Level:      30
Time taken for tests:   0.423 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Non-2xx responses:      1000
Total transferred:      567000 bytes
HTML transferred:       316000 bytes
Requests per second:    2364.62 [#/sec] (mean)
Time per request:       12.687 [ms] (mean)
Time per request:       0.423 [ms] (mean, across all concurrent requests)
Transfer rate:          1309.32 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    2   1.7      2      13
Processing:     4   10   3.4      9      33
Waiting:        1    8   3.0      7      32
Total:          6   12   3.6     11      35

Percentage of the requests served within a certain time (ms)
  50%     11
  66%     12
  75%     13
  80%     14
  90%     18
  95%     21
  98%     22
  99%     23
 100%     35 (longest request)

Les temps de réponse d’Apache sont tout à fait correcte.

Apache distant

Server Software:        Apache/2.2.22
Server Hostname:        94.125.162.127
Server Port:            80

Document Path:          /pydio
Document Length:        316 bytes

Concurrency Level:      30
Time taken for tests:   4.180 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Non-2xx responses:      1000
Total transferred:      714000 bytes
HTML transferred:       316000 bytes
Requests per second:    239.22 [#/sec] (mean)
Time per request:       125.408 [ms] (mean)
Time per request:       4.180 [ms] (mean, across all concurrent requests)
Transfer rate:          166.80 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   0.1      1       2
Processing:    31   99 425.2     36    4178
Waiting:       31   98 425.2     36    4178
Total:         32   99 425.3     37    4180

Percentage of the requests served within a certain time (ms)
  50%     37
  66%     40
  75%     42
  80%     45
  90%     71
  95%     96
  98%    165
  99%   3161
 100%   4180 (longest request)

Conclusion

Leur serveur répond correctement, on ne ressent aucune latence au niveau de la console, ce qui est vital selon moi. Je ne me vois pas perdre 10 minutes pour installer quelques malheureux paquets. Un dépôt interne est disponible, ce qui nous accélère les mises à jour.

Point intéressant, leur image Debian Wheezy est à jour dès l’installation. Je trouve que cela représente une qualité de travail de la part d’Ikoula. Et ils ont l’air d’attacher de l’importance à la sécurité. D’ailleurs ils tiennent à valider l’identité des propriétaires de leurs serveurs afin d’éviter des utilisations illicites.

Au niveau performance CPU, cela m’a un peu déçu, je m’attendais à mieux pour ce prix. Mais il faut voir comment les ressources sont partagées via Hyper-V. Lancer un stress-test sur des ressources strictement réservées par instance ne donne pas le même résultat que sur un système permettant l’overhead tant que les ressources sont disponibles comme OpenVZ.

Au niveau réseau et I/O rien à redire c’est plus que correcte pour ce prix. La stabilité, la rapidité et le temps de réponse sont au rendez-vous.

Je conclurai par conseiller ce type de serveur pour des applicatifs légers avec traitement de données et stockage comme un serveur web (dans la limite des 40Go proposés).

Un autre point à souligner pour les utilisateurs Windows Server, ils proposent une licence incluse dans leur offre. Cela peut faire une différence.

L’article [dossier] Comparatif des offres hosting VPS – Ikoula Flex’Servers NG 1 CPU est apparu en premier sur Mon linux.

Vous aurez le même problème avec un certificat signé utilisé pour un autre FQDN.

Voici le type d’erreur rencontré :

git clone https://devel.domain.tld/git
Cloning into 'git'...
error: SSL: certificate subject name (git.domain.tld) does not match target host name 'devel.domain.tld' while accessing https://devel.domain.tld/git/info/refs

Pour pouvoir obtenir le projet en local, il faut passer par une variable d’environnement et faire ceci :

env GIT_SSL_NO_VERIFY=true git clone https://devel.domain.tld/git/projet

Cloning into 'projet'...
Username for 'https://devel.domain.tld': belgotux
Password for 'https://belgotux@devel.domain.tld':
remote: Counting objects: 10304, done.
remote: Compressing objects: 100% (4953/4953), done.
remote: Total 10304 (delta 5801), reused 4769 (delta 3309)
Receiving objects: 100% (10304/10304), 35.07 MiB | 7.18 MiB/s, done.
Resolving deltas: 100% (5801/5801), done.

Une fois le projet présent, on navigue dans le dossier pour définir de manière permanente l’option de non vérification de certificat SSL valide :

cd projet
git config --global http.sslverify false

On peut désormais utiliser git avec les commandes classiques.

L’article git – problème SSL certificate subject name does not match est apparu en premier sur Mon linux.

Cela tien en 3 petites étapes détaillées dans cet article :

• Préparer le serveur Cyrus
• Préparer le serveur Exchange de destination
• Installer IMAPsync et le script de migration

Préparer le serveur Cyrus

Dans mon cas c’est un Debian vieillissant en Lenny avec Cyrus 2.2.

Il faut d’abord créer un utilisateur admin dans Cyrus, ou utiliser l’utilisateur admin de base nommé ‘cyrus’.

Ensuite on autorise cet utilisateur à lire toutes les boites mails de cette façon :

# cyradm --user cyrus localhost
	sam user.* cyrus lrswipcda
	sam user.*.* cyrus lrswipcda

Pour vérifier, il suffit d’aller lire les droits d’une mailbox au hasard :

localhost> lam user. testuser*
	user. testuser:
	   testuser lrswipcda
	user. testuser.drafts:
	   testuser lrswipcda
	  cyrus lrswipcda
	user. testuser.sent:
	   testuser lrswipcda
	  cyrus lrswipcda
	user. testuser.trash:
	   testuser lrswipcda
	  cyrus lrswipcda

Autoriser les connexions IMAPS dans Cyrus si ce n’est déjà fait (dans mon cas c’était un webmail exclusivement donc pas d’IMAP actif)

Editer le fichier /etc/cyrus.conf et remplacer l’adresse IP d’écoute :

imaps		cmd="imapd -s -U 30" listen="10.xxx.xxx.xxx:imaps" prefork=0 maxchild=100

Dans le fichier /etc/imapd.conf rajouter les lignes suivantes :

tls_cert_file: /var/imap/server.pem
tls_key_file: /var/imap/server.pem

Il vous faut avoir généré une clé et un certificat SSL autosigné au préalable.

Préparer le serveur Exchange de destination

Sous Windows Server 2008R2, il vous faut créer un utilisateur qui est administrateur pour l’OU utilisée pour les comptes Exchange à migrer. C’est cette utilisateur qui sera utilisé par le script d’IMAPsync.

Activer IMAPs si ce n’est déjà fait.

Installer IMAPsync et le script de migration

Imapsync peut être installé sur n’importe quelle machine linux, étant donné que c’est un client qui se connecte aux 2 serveurs IMAP. Il est même préférable de ne pas le mettre sur le serveur Cyrus, mais sur un autre serveur ou pc linux afin de répartir la charge. Celle-ci est assez élevée pour le serveur Cyrus durant les transferts.

Imapsync ne se trouve pas sur les dépôts de Debian Wheezy, il faut donc l’installer manuellement. Voici la liste des dépendances et les commandes :

apt-get install libdate-manip-perl libterm-readkey-perl libterm-readkey-perl libdigest-hmac-perl libdigest-hmac-perl libdate-manip-perl libmail-imapclient-perl makepasswd rcs perl-doc git

cd /tmp

git clone git://github.com/imapsync/imapsync.git

cd imapsync/

sh examples/install_modules_linux.sh

make install

Et voici le script qui permettra de migrer les boites mails via un simple fichier texte en entrée avec les identifiants des utilisateurs :

• Les identifiants doivent être les mêmes des 2 côtés dans ce script imapsync_cyrus_exchange.sh
• Les comptes à migrer se trouvent dans le fichier compte-to-migrate.txt
• le mot de passe de l’administrateur cyrus se trouve dans un fichier cyrusadmin.pass
• le mot de passe de l’administrateur exchange se trouve dans un fichier passwd_ad.pass

#!/bin/bash
# imapsyncrun.sh. Script to migrate imap Cyrus to Exchange
DATE=`date +%m%d%y_%H:%M`
LOGFILE="imapsync_migration.log"
echo "IMAPSync starting..  $DATE" >> $LOGFILE

# Begin 'for' loop, calling the list of user names already collected
for ACCTNAME in `cat compte-to-migrate.txt`
do

    /usr/bin/imapsync --buffersize 8192000 --nosyncacls --subscribed --syncinternaldates --ssl1 --host1 IP_CYRUS \
     --user1 $ACCTNAME --authuser1 cyrus --passfile1 cyrusadmin.pass --host2 IP_EXCHANGE --user2 $ACCTNAME@DOMAINE --authuser2 ADMIN_WINDOWS --passfile2 passwd_ad.pass --tls2 --noauthmd5 --include 'INBOX' --regextrans2 's/drafts/Brouillons/' --regextrans2 's/sent/&AMk-l&AOk-ments envoy&AOk-s/' --regextrans2 's/trash/&AMk-l&AOk-ments supprim&AOk-s/' --regextrans2 's/INBOX/INBOX/'
    echo Done with $ACCTNAME on $DATE >> $LOGFILE
done

echo "" >> $LOGFILE
echo "IMAPSync Finished..  $DATE" >> $LOGFILE
echo "------------------------------------" >> $LOGFILE

Remarques

On peut voir des options du style :

--regextrans2 's/drafts/Brouillons/'

Il faut savoir que sous Cyrus, peut importe la langue de l’utilisateur, le dossier IMAP porte un nom en anglais. Alors que sous Exchange, le nom du dossier est en fonction de la langue de l’utilisateur. Si vous travaillez dans un environnement multi-langues vous aller donc créer de nouveaux dossiers dans l’Exchange lors de la synchro et les utilisateurs d’une autre langue devront déplacer leurs emails ou renommer le dossier.

Si vous voulez éviter au maximum les frustrations des utilisateurs à renommer le dossier dans leur langue natale, vous pouvez toujours faire une liste des utilisateurs par langue en vous basant sur le LDAP. Ensuite, vous modifierez le script et l’exécuterez autant de fois que vous aurez de langues différentes dans l’entreprise.

L’article Migrer un serveur Cyrus vers Exchange via Imapsync est apparu en premier sur Mon linux.