HOAB

Le problème :

I know that many post have been written on the subject, but has I do not had a quick solution. Here is some few more information.

When connecting to webex from Linux, I had no sharing.

Solution :

First I used Firefox 64 and JVM 64. It doesn't work. Whatever I read on the net (from this link, or there).

So :

1. Install i386 architecture
2. install firefox32 (< 52.x otherwise Java is not working for now)
3. create a separate profile
4. install missing packages... (when starting firefox32)
5. install 32bits JVM
6. create a link to the JVM plugin in the new profile
7. remove any shared plugin (for example JVM 64bits plugin in shared plugins library) : use plugins directory in profile

This is a quick & dirty, I'll try to update it after.

Useful tips :

• about:plugins in firefox
  • if the 32bits plugins is not there, or the JVM64 is still there, don't go further, correct this
• http://java.com/verify/
• remove webex directory : ~/.webex
• install missing packages for webex (ldd tips)
• sometimes it can be long when you are behind a proxy

Le problème :

Sous Linux, lorsque je clique sur un lien depuis une autre application que Firefox (SublimeText, Thunderbird, Terminator, etc...), ça mouline et rien ne s'ouvre ou j'ai le message :

another instance is already running

Solution :

En cherchant sur internet (ex sur google) on trouve pas mal de chose : des bugs, des flags à changer (coucou -no-remote !), des options à modifier dans la console, j'ai cherché les configurations de mon environement X (...

Rien de tout cela n'a fonctionné chez moi.

Et la solution est venu d'ici :

https://support.mozilla.org/t5/Customize-controls-options-and/Hyperlinks-in-Messages-Not-Working/ta-p/14770

Moi qui croyait que mon Firefox était déjà mis comme navigateur par défaut, pas du tout. (Peut-être est-ce du à un mélange entre Firefox-ESR, Firefox & Iceweasel étant sous Debian....). Bref, une fois remis par défaut, il m'a ouvert les 50 liens sur lesquels j'avais cliqué précédemment....

Et effet du hasard ou non, les liens non cliquables depuis le plugin Exchange EWS dans les événements fonctionnent...

https://github.com/Ericsson/exchangecalendar/issues/116

Le problème :

Légèrement décrit ici : http://hoab.fr/shaarli/?TrwlkA

En réalité suivant le mode de protection, la solution ci-dessus ne marche pas.

Solution :

Si on a un noyau normal, alors hidepid n'est pas *encore* activé par défaut. Dans ce cas, tous les utilisateurs voient les processus et le problème n'existe pas.

Si le mode hidepid a été activé, l'activation de l'option gid permet d'avoir un groupe priviligé qui permet ceci.

Si le patch grsecurity est activé (si on trouve un -grs dans le nom du noyau "uname -a") c'est plus compliqué :

• si le noyau a été compilé avec un groupe priviligié : retrouver ce groupe et on a le même comportement que le hidepid
• sinon :
  • recompiler le noyau pour l'ajouter
  • changer de noyau pour avoir une version sans grs
  • utiliser les mécanismes des sudoers (http://hoab.fr/shaarli/?qBeGWA)

J'ai choisi la dernière solution dans un premier temps, le problème étant de reprendre un noyau avec les mêmes options que celui qui existe...

Le problème :

Je veux migrer en douceur et de manière transparente un serveur de courier d'un serveur A vers un serveur B.
Le serveur A est un qmail/vpopmail/courier-imap.
Le serveur B est un postfix/dovecot
Go !

Solution :

Pour palier au temps de propagation des DNS qui peut être rapide ou pas, l'idée est donc :

Serveur B : préparation

<domaine.com> mail._domainkey.<domaine.com>

1. créer dans postfixadmin sur le serveur B le nom de domaine à gérer
2. générer la clé DKIM pour ce nouveau domaine (cf configuration DKIM multi-domaine)
3. vérifier le domaine (cf post 10/10)
4. créer les boites aux lettres, j'en ai peu, mais il y a des scripts de migration à partir des vpasswd a priori (ou ça en fait)
5. via thunderbird portable, et mes configurations, je créé des comptes et je teste l'envoi et la réception

IMAP
ip du serveur (le DNS n'est pas migré), port 143, STARTTLS, mot de passe non chiffré

SMTP
ip du serveur (le DNS n'est pas migré), port 587, STARTTLS, mot de passe non chiffré

Serveur A : relay

Le serveur B étant prêt à gérer les mails, on redirige le trafic SMTP du serveur A vers le B pour ce domaine.

Un guide ici.

1. Vérifier la présence de <domaine.com> dans /var/qmail/control/rcpthosts
2. Supprimer la référence à <domaine.com> dans /var/qmail/control/smtproutes
3. Ajouter la redirection dans : /var/qmail/control/smtproutes

<domaine.com>:<IP serveur B>

4. redémarrer qmail
5. Tester l'envoi d'un email en utilisant le DNS mail.<domaine.com>, il passe par serveur A et est forwardé au serveur B

DNS : bascule

Modifier les DNS

Serveur A/B : recopier les boites aux lettres

Via un rsync plusieurs jours avant si les boites sont volumineuses, c'est la copie qui est longue, la conversion est rapide (quelques fichiers à modifier).

Le script de migration est ici : http://wiki.dovecot.org/Migration/Courier

Donc :

1. recopier les boites courier-map

# Serveur A
cd /home/vpopmail/domains
tar zcf <domaine.com>.tgz <domaine.com>
scp <domaine.com>.tgz <Serveur B>:/home/vmail/<domaine.com>/tmp_migrate

# OU rsynch
cd /home/vpopmail/domains
rsync -razh --delete root@<serveur A>:/home/vpopmail/domains/<domaine.com> .

2. les extraire

# Serveur B
cd /home/vmail/<domaine.com>/tmp_migrate
tar zxf <domaine.com>.tgz

3. les convertir

 ./courier-dovecot-migrate.pl <domaine.com> --recursive 
# si ok
 ./courier-dovecot-migrate.pl <domaine.com> --recursive --convert

4. les transférer dans la nouvelle boite

chown -R <user dovecot:user dovecot> *
cp -r <domaine.com>/* /home/vmail/<domaine.com>/

Le problème :

En complément à cet article http://hoab.fr/postfix-et-10-10-aux-tests-antispam

Solution :

C'est tout simple, c'est pour tracer.

Par rapport aux tutoriels référencés dans l'article précédent, la configuration /etc/opendkim.conf :

#Domain & Selector & KeyFile ignore avec Keytable

#Domain			origames.fr
#Selector		mail
#KeyFile		/etc/dkim/mail.private

KeyTable		/etc/dkim/KeyTable
InternalHosts		/etc/dkim/TrustedHosts
SigningTable		/etc/dkim/SigningTable

On demande à opendkim d'aller chercher les clés dans un fichier plutôt que d'avoir une clé unique.

1. ajout de la ligne du domaine dans : /etc/dkim/SigningTable

<domaine.com> mail._domainkey.<domaine.com>

2. ajout de la ligne du domaine dans : /etc/dkim/TrustedHosts

<domaine.com>

3. ajout de la ligne du domaine dans : /etc/dkim/KeyTable

mail._domainkey.<domaine.com> <domine.com>:mail:/etc/dkim/keys/<domaine.com>/mail.private

4. générer la clé DKIM

cd /etc/dkim/keys/<domaine.com>/
opendkim-genkey -t -s mail -d <domaine.com>

Et voilà, ça roule.