Netexpertise

Vous venez de récupérer un serveur où est installé le rôle Remote Desktop Services (RDS) et malheureusement, le disque C: commence à manquer de place, les profils RDS se créant sur ce même volume.
Ca tombe bien, il vous reste une place énorme sur le lecteur D:, mais comment procède-t-on?

Paramétrer le chemin des nouveaux profils

On peut faire une GPO qui crée les nouveaux profils dans D: comme ceci:

-> Computer Configuration
-> Administrative Templates
-> Windows Components
-> Remote Desktop Services
-> Remote Desktop Session Host
-> Profiles
-> Set path for Remote Desktop Services Roaming Profiles

Ca fonctionne pour les nouveaux profils mais il faut migrer les existants.

Migrer les profils RDS existants

Migrez le dossier utilisateur de C: vers le nouveau lecteur et lui donnez-lui les bons droits. Il faut tout d’abord supprimer l’entrée dans
-> Panneau de configuration
-> Comptes d’utilisateurs
-> Configurer les propriétés avancées de profils utilisateurs.

Si les anciens profils se connectent avec un profil temporaire, il faut aussi:
– Supprimer l’entrée dans le registre HKLM\Software\Microsoft\Windows NT\CurrentVerison\ProfileList\S-1-5-21… avec une clé ProfileImagePath correspondant au chemin du profil de l’utilisateur
Avantage: tous les nouveaux profils seront à ce nouvel emplacement

ou

Modifier le chemin dans la clé de registre ci-dessus, déplacer le répertoire et donner les droits à l’utilisateur.
Les nouveaux profils seront toujours créés sur C: mais vous pouvez migrer sur D: les anciens à votre guise, et répartir les données sur les 2 volumes.

Le mieux est évidemment de définir une GPO dès le départ sur un volume dédié autre que le C:, sinon vous devrez migrer les profils RDS tôt ou tard.

 

Tags: GPO, RDS, Remote Desktop, Windows

Vous avez un serveur (ou cluster) Exchange qui communique avec l’extérieur via un relais mail (appelé aussi hôte actif dans la terminologie Microsoft), dans une DMZ le plus souvent. Vous aimeriez apporter de la haute disponibilité à cette infrastructure, qui pourrait couvrir un plan de reprise d’activité idéalement. On peut y parvenir en doublant les serveurs sur un second site – site B – dans le cas où le site A n’est plus disponible, ce qui signifie un relais sur chaque site, avec sa propre connexion Internet.

Sécuriser le trafic entrant

J’utilise Symantec Messaging Gateway comme relais mail: c’est puissant, facile à configurer, et peut être installé comme machine virtuelle. De plus c’est gratuit si vous avez acheté des licences Symantec antivirus. Vous pouvez utiliser celui de votre choix bien évidemment.

Router les mails entrants consiste à créer des entrées DNS MX pour chaque relais mail et à transférer les mails aux serveurs Exchange. Les serveurs mail externes basculeront automatiquement sur le second relais si le premier devient indisponible.

Bascule du trafic sortant

Router les mails vers l’extérieur peut s’avérer un peu plus compliqué.
Si vous ajoutez un 2nd relais mail au connecteur d’envoi Exchange, les emails seront répartis sur les 2 relais qu’ils soient actifs ou non, et aucune bascule n’aura lieu. Mais il existe un moyen.
 
Créez des entrées DNS pour chaque relais, chacun dans leur sous-domaine:
SiteA: RelayA.siteA.mondomaine.com
SiteB: RelayB.siteB.mondomaine.com
Il peut s’agir d’alias pointant vers les noms d’hôtes réels.

Créez 2 MX pour le sous-domaine siteA, le relais local ayant le plus petit nombre (priorité la plus haute):

siteA.mondomaine.com.	3600	IN	MX	 5 relayA.siteA.mondomaine.com.
siteA.mondomaine.com.	3600	IN	MX	10 relayB.siteB.mondomaine.com.

Faites la même chose pour siteB s’il y a aussi un serveur Exchange sur ce site.
 
Tout ce qu’il vous reste à faire, c’est de créer un connecteur d’envoi pointant sur siteA.mondomaine.com. Avant de résoudre le nom d’hôte DNS, Exchange essaiera de faire un MX lookup, même si cela n’est pas clairement détaillé sur l’EAC d’Exchange.

Avec cette solution flexible, vous avez des tas de configurations possibles. Vous pouvez:
– Envoyer du trafic au relais local et basculer sur le site distant
– Répartir le trafic sur les 2 sites et basculer si l’un tombe (même priorité MX)
– Répartir le trafic sur 2 relais mail locaux et basculer vers un seul distant (2 MX aux priorités hautes identiques et une plus basse pour le relais distant)

Conclusion

Tout est complètement automatisé si un relais devient injoignable et la mise en place de nouveaux relais se fait simplement par DNS. Vous avez maintenant une architecture redondante avec la haute disponibilité.

 

Tags: Exchange, haute disponibilité, Mail, Microsoft

En générant un certificat Microsoft Exchange (ou IIS), profitez-en pour y ajouter des noms de domaine supplémentaires et le réutiliser sur un serveur web Apache. Cela vous fera économiser du temps et de l’argent, à moins que votre CA fournisse des certificats pour des plate-formes multiples.

PFX est un format d’échange populaire pour les logiciels Microsoft comme Exchange ou IIS. Il s’agit d’un fichier d’archive PKCS#12 qui contient un certificat et la clé privée correspondante. Il peut aussi comporter d’autres choses comme le certificat CA.
Tout d’abord, copiez le fichier pfx généré avec Exchange sur le serveur web Apache où vous devriez avoir tous les outils nécessaires pour extraire et importer le certificat PFX sur Apache.

Extraire la Clé et le Certificat du Fichier PFX

Extraire la clé privée du fichier PFX avec openssl. Entrez le mot de passe s’il vous est demandé.

openssl pkcs12 -in cert.pfx -nocerts -out enc.key -nodes

Puis extraire le certificat

openssl pkcs12 -in cert.pfx -nokeys -out cert.crt

En enfin, déchiffrement de la clé privée RSA

openssl rsa -in enc.key -out dec.key

Importer la Clé et le Certificat dans Apache

 
Déplacez le certificat et la clé privée dans les répertoires appropriés (Sur Linux Redhat), et donner les droits au propriétaire en lecture seule

mv cert.crt /etc/pki/tls/certs/
mv dec.key /etc/pki/tls/private/
chmod 600 /etc/pki/tls/private/dec.key

Sans le chmod, le redémarrage d’Apache retourne une erreur.
 
Si selinux est activé, lancez

restorecon -RvF /etc/pki

pour donner les bons droits aux nouveaux fichiers, ou vous obtiendrez le message d’erreur suivant:
[error] (13)Permission denied: Init: Can’t open server certificate file /etc/pki/tls/certs/cert.crt
 
Déclarez le nouveau certificat dans le fichier de configuration de l’hôte virtuel Apache:
SSLCertificateFile /etc/pki/tls/certs/cert.crt
SSLCertificateKeyFile /etc/pki/tls/private/dec.key
 
Et appliquez les modifications:

/etc/init.d/httpd reload

 
Vous avez maintenant le même certificat sur Exchange (ou IIS au format PFX) et le serveur web Apache. Le certificat peut être utilisé sur d’autres serveurs web comme Nginx par exemple.

Vérifiez avec votre autorité de certification en premier lieu. Certains fournissent des formats de certificats multiples pour des logiciels variés, ce qui peut vous épargner ces manipulations.

 

Tags: Apache, Certificat, Exchange, iis, Openssl, SSL

Je veux faire un peu de ménage sur notre IBM i principal à commencer par les files de travaux (JOBQ) dans lesquelles s’exécutent les travaux des utilisateurs. La plupart des utilisateurs ont leur propre JOBD, ce qui ne devrait pas être. La JOBQ des utilisateurs est définie dans leur JOBD (Job Description). Une JOBD référence une JOBQ et peut être affectée à autant d’utilisateurs que souhaité. La première chose dont j’ai besoin est la liste des JOBQ de tous les utilisateurs.

Je peux récupérer facilement les descriptions de travail avec la commande WRKUSRPRF mais récupérer toutes les files d’attente est un peu plus délicat.
Mais en se connectant à PASE, on y parvient facilement. On peut même affecter des nouvelles JOBD à des profils en se basant sur des critères définis.

Liste JOBD/JOBQ par Profil Utilisateur

Connectez-vous à l’environnement PASE soit en exécutant ‘CALL QP2TERM’ ou en SSH si le service a été activé.
Copiez le code shell suivant dans un fichier (appelons-le listJobq.sh) dans l’IFS, dans votre répertoire maison par exemple, rendez-le exécutable
chmod +x listJobq.sh

et lancez:
./listJobq.sh

#!/QOpenSys/usr/bin/ksh

IFS='
'
# Assurez-vous que la librairie ADMIN existe
system "DSPUSRPRF USRPRF(*ALL) OUTPUT(*OUTFILE) OUTFILE(ADMIN/USERLIST)"

printf "%11s%11s%11s\n" "USRPRF" "JOBD" "JOBQ"

for i in $(db2 "select upuprf,upjbds from ADMIN.USERLIST" | \
      sed -e '1,3 d' -e '/^$/ d' | sed -e '$ d'); do
  unset IFS
  set -A user $i
  jobq=`system -i "DSPJOBD JOBD(${user[1]})" | awk '/^ Fi/ {print $NF;exit;}'`
  printf "%11s%11s%11s\n" "${user[0]}" "${user[1]}" "$jobq"
done

Cela génère une liste de USRPRF / JOBD / JOBQ. La plupart des profils utilisent la JOBD DEFAULT qui envoie les travaux des utilisateurs dans la JOBQ QBATCH si l’utilisateur ne la change pas au lancement du job.

     USRPRF       JOBD       JOBQ
  ABERTRAND    DEFAULT     QBATCH
  GBOUBOURS    DEFAULT     QBATCH
    IBURNET         IT      QPGMR
   PBUISSON    DEFAULT     QBATCH
    PMARTIN    DEFAULT     QBATCH
        ...        ...        ...

 
Le système pourrait retourner un message « db2: cannot execute » ou « /usr/bin/db2: Permission denied ». Dans ce cas, créez un lien symbolique comme ceci:
ln -s /QOpenSys/usr/bin/qsh /QOpenSys/usr/bin/db2
La raison est détaillée dans cette explication.

Script Bash Optimisé sur PASE

Un inconvénient est la lenteur de la commande « system ». L’option -i la rend un peu plus rapide mais on peut améliorer un peu. Si vous avez installé le paquet OPS (Open Source) d’IBM avec les PTF correspondantes et bash, vous pouvez essayer cette version optimisée avec tables de hachage en bash. Les packages opensource peuvent dorénavant se gérer graphiquement via le client ACS.
On stocke les jobd/jobq dans une table de hachage qui agit comme un cache puisque les descriptions de travail retournent toujours les mêmes JOBQ. Si beaucoup d’utilisateurs ont la même JOBD, ca peut être très efficace (35 fois plus rapide dans mon cas). Ainsi, cette astuce permet d’obtenir de meilleures performances sur les shells scripts qui peuvent être lents sur IBM i comparés à leurs homologues x86.
 

#!/usr/bin/bash

IFS='
'
declare -A JOBQ

# Assurez-vous que la librairie ADMIN existe
system "DSPUSRPRF USRPRF(*ALL) OUTPUT(*OUTFILE) OUTFILE(ADMIN/USERLIST)"

printf "%11s%11s%11s\n" "USRPRF" "JOBD" "JOBQ"

for i in $(db2 "select upuprf,upjbds from ADMIN.USERLIST" | \
      sed -e '1,3 d' -e '/^$/ d' | sed -e '$ d'); do
  unset IFS
  # Assigne utilisateur et jobd dans user[0] et user[1]
  user=($i)
  # Ajoute la jobq à la table de hachage
  if [ -z ${JOBQ[${user[1]}]} ]; then
    jobq=`system -i "DSPJOBD JOBD(${user[1]})" | awk '/^ Fi/ {print $NF;exit;}'`
    JOBQ[${user[1]}]=$jobq
  fi
  printf "%11s%11s%11s\n" "${user[0]}" "${user[1]}" "${JOBQ[${user[1]}]}"
done

 

Tags: AS400, IBM i, iSeries, shell

Changer le Propriétaire Via le Terminal IBM i

Il existe de nombreuses façons de changer le propriétaire d’un object sur IBM i. Avec CHGOBJOWN pour un simple objet, ou WRKOBJOWN puis 9 pour chaque objet si vous voulez traiter tous les objets appartenant à quelqu’un.
Changer le propriétaire de milliers d’objets de cette façon risque de prendre énormément de temps!
 
Des sites web spécialisés comme itjungle proposent des solutions plus rapides comme:

CHGOWN OBJ('/qsys.lib/ma_lib.lib/*.*') NEWOWN(nouveau_proprio) RVKOLDAUT(*YES)

qui est un bon moyen de changer le propriétaire de tous les objets AS400 d’une bibliothèque donnée.
 
Mais il y a plus puissant si vous n’avez rien contre QSHELL/PASE (lancez QSH ou CALL QP2TERM), ou connectez-vous en SSH.

Commandes Avancées de Propriétaire sur QSH/PASE

Vous pouvez vous déplacer dans le répertoire d’une bibliothèque avec cd. Ajoutez toujours .LIB au nom de la bibliothèque

cd /QSYS.LIB/MABIB.LIB

 
Vous pouvez facilement compter le nombre d’objets:

$ ls -1 | wc -l
    6228

 
Affichez le propriétaire de tous les objets avec ls et more pour afficher une page à la fois (peut être lent si vous avez beaucoup d’objets)

$ ls -l | more
total 190672
drwx---rwx    2 proprio    0             28672 Jan  5 10:37 $BUL100.FILE
drwx---rwx    2 proprio    0             20480 Jan  5 10:37 $BUL200.FILE
[...]

 
Changez le propriétaire de tous les objets avec chown:

chown nouveau_proprio *.*

Vous pouvez aussi être plus spécifique avec *.FILE ou MON_*.PRG.
 
Et voici où ca devient vraiment intéressant. Vous pouvez changer tous les objets qui n’ont pas de propriétaire

find . -nouser | xargs chown nouveau_proprio

A utiliser avec précaution, lisez la suite…
 
Vous pouvez aussi changer tous les objets appartenant à quelqu’un en particulier

find . -user ancien_proprio | xargs chown nouveau_proprio

Idéal pour réaffecter les objets des personnes ayant quitté la société avant de supprimer leur compte!

Longueur du Nom d’Utilisateur AS400 et Autres

find cherche aussi dans les sous-répertoires.
 
Il se peut que vous ayiez une erreur unknown username:

$ chown lgusername AABL01WC.PGM
chown: lgusername is an unknown username.

Vous devez alors récupérer l’id utilisateur dans le profil AS400 et utiliser ce numero à la place, si le nom d’utilisateur fait plus de 8 caractères:

$ chown 1073 AABL01WC.PGM

Voyez cette note sur le site d’IBM. Il vaut mieux donc n’avoir que des noms d’utilisateurs de 8 caractères ou moins sur iSeries.
 
Sachant le problème de longueur de nom d’utilisateur, la commande « find . -nouser » retourne aussi les fichiers/objets appartenant à des profils faisant 9 ou 10 caractères! Dommage qu’IBM n’aient pas paramétré la longueur maxi des utilisateurs à 10 aussi pour PASE.
 
Un dernier conseil: connectez-vous via SSH pour avoir ainsi un terminal dans une fenêtre plus grande.

 

Tags: AS400, IBM i, iSeries