IBM i FTP et longs mots de passe

FTP et longs mots de passe

Q : Nous avons récemment modifié notre niveau de sécurité pour accepter des mots de passe de 120 caractères. Depuis lors, mes ID et mots de passe utilisateur sont rejetés quand j’essaie de me connecter au système iSeries via FTP. Si je ramène mon mot de passe à 10 caractères ou moins, je me connecte normalement. FTP est-il allergique à de longs mots de passe ?

R : Avant même qu’IBM n’ait modifié l’OS pour permettre des mots de passe de 120 caractères, FTP acceptait de longs mots de passe. Par exemple, lorsqu’on met en place un FTP anonyme, la convention demande une adresse e-mail comme mot de passe.

Votre problème semble se situer dans une phase d’authentification intermédiaire. Consultez le log du serveur FTP et, si vous utilisez un programme de sortie FTP logon, le log de ce programme. Si vous utilisez un programme de sortie FTP, il se peut qu’il ne supporte pas de longs mots de passe. Il est facile de s’en assurer en désactivant temporairement le programme de sortie. Si vous pouvez alors vous connecter avec un long mot de passe, ce programme est en cause.

Réponses de Ping en double

Q : Quand j’envoie un ping à une adresse IP de serveur IBM i à distance, j’obtiens le message d’avertissement TCP3216: Duplicate ping reply. Quelle pourrait en être la cause ? La configuration TCP/IP du serveur à distance semble correcte.

R : Ce problème est le plus souvent causé par deux ordinateurs du réseau à distance avec la même adresse IP. Les deux ordinateurs répondent à votre ping, d’où le message duplicate reply. Si tel est le cas, toutes les requêtes ou presque devraient provoquer une réponse en double. Le remède est simple : une adresse IP unique pour chaque unité du réseau à distance.

Une autre cause pourrait être un masque subnet incorrect dans la configuration TCP/IP du serveur à distance. Par exemple, si le subnet à distance est 192.168.1.0/25, qui a un masque de 255.255.255.128, et si votre serveur est à 192.168.1.127 avec un masque de 255.255.255.0, le serveur est en réalité configuré sur l’adresse broadcast du réseau. Une telle configuration fera que les autres serveurs du même réseau répondront au ping. La solution consiste à corriger l’adresse IP et le masque subnet sur le serveur.

Si ce problème n’est pas permanent, cherchez ailleurs : défaut de câble, de commutateur, de routeur, ou de carte réseau, provoquant de mauvaises données sur le réseau. S’il se produit très rarement (un ping sur cinq mille ou moins), c’est un incident normal de traitement des paquets sur le réseau concerné, et vous ne devriez vous en soucier que si vous constatez d’autres problèmes de performance.

— Scott Klement et Mel Beckman

Configurer Virtual Ethernet

Q : Nous avons un système Power 5 V5R4 (utilisant HMC 6.1.2) avec plusieurs LPAR. À l’origine, ces LPAR étaient des machines distinctes, et nous transférions les objets entre systèmes à l’aide de FTP et DDM. Nous avons continué à procéder ainsi même après le passage aux LPAR.

Mais maintenant nous voulons améliorer la performance et nous envisageons Virtual Ethernet. En particulier, un LPAR héberge notre serveur web d’entreprise, ce qui nous connecte à une DMZ non protégée à l’extérieur du pare-feu. Je soupçonne que c’est pour cela que le transfert de données avec DDM est particulièrement lent : il utilise notre liaison Ethernet physique du côté public de notre connexion Internet. Virtual Ethernet peut-il prendre en charge les communications entre les LPAR quel que soit l’endroit où l’adresse IP des LPAR se connecte ?
Nous n’avons pas d’expérience en matière de configuration de Virtual Ethernet, parce que ce sont nos techniciens de maintenance du matériel qui ont mis en place nos systèmes quand nous sommes passés à LPAR. Existe-t-il quelque documentation, cours, ou tutoriel expliquant le processus ?

R : Il y a trois étapes principales :
1. Configurer les IOA virtuels (en utilisant le HMC)
2. Créer les descriptions de lignes
3. Configurer TCP/IP (interfaces, routes, etc.)

Les documents en ligne suivant vous guideront :

Etape 1 :
System i (POWER5)—Configuring a Virtual Ethernet Adapter Using Version 6 of the HMC

Etapes 2 & 3 :
Partitions logiques i5/OS : Virtual Ethernet
Scénario: Créer un Ethernet virtuel pour des communications Interpartition
Egalement, les IBM Redbooks suivants vous donneront plus de détails et de méthodes :
IBM i5/OS IP Networks: Dynamic (voir chapitre 13)
LPAR Configuration and Management Working with IBM eServer iSeries Logical Partitions (voir chapitre 10)

Ce n’est qu’un aperçu de la documentation existante. La plupart de ces sources font référence aux menus SST ou à iSeries Navigator pour créer les IOA virtuels, mais ces outils ne sont pas disponibles quand les partitions sont gérées avec un HMC. Vous devrez vous reporter à la documentation HMC de votre système pour trouver les procédures de configuration d’IOA équivalentes.

Comme l’une de vos interfaces est directement connectée à l’Internet public, vous devrez veiller à ce que tous les accès aux commandes de configuration TCP/IP soient limités à une poignée de collaborateurs, pour sécuriser l’utilisation de Virtual LAN. En effet, vous utilisez la configuration TCP/IP normale pour les Virtual LAN comme ces LAN physiques, et n’importe quel détenteur de droits d’administration réseau pourrait reconfigurer une interface Virtual LAN.

— DéesseT et Satid Singkorapoom

Enlever AS400MM des e-mails

Q : Quand j’envoie un e-mail de mon i-Series, l’adresse de l’envoyeur est du type jsmith-systemname@AS400MM.mycompanyname.org. Je ne vois vraiment pas d’où vient le « AS400MM », et nos e-mails sont rejetés par leurs destinataires parce que le AS400MM invalide notre nom de domaine (il n’y a pas d’entrée DNS pour lui).

R : Le problème est que le profil utilisateur envoyeur n’a pas un nom SMTP spécifié ; donc, le serveur de e-mail en crée un qu’il croit unique, en ajoutant le nom du système au nom de l’utilisateur, et en faisant précéder le nom de domaine du nom de l’hôte interne.

La correction consiste à configurer spécifiquement le nom de l’utilisateur pour chaque profil utilisateur qui enverra du e-mail, via la commande WRKDIRE (Work with Directory Entries). Exécutez WRKDIRE sans arguments, afin d’afficher une liste des entrées de répertoire configurées. Trouvez l’entrée utilisateur à l’origine du e-mail et prenez l’option 2 pour modifier cette entrée (ou, si l’utilisateur n’a pas une entrée, appuyez sur F6 pour en créer une). Ensuite appuyez sur F19 (Change name for SMTP) et remplissez l’ID utilisateur SMTP (par exemple, jsmith) et le nom de domaine (par exemple, mycompanyname.org).

Désormais, tout e-mail établi à partir de ce profil utilisateur aura une adresse électronique d’envoyeur jsmith@mycompanyname.org. Pourvu que vous ayez des entrées MX et IN-ADDR DNS correctes pour votre serveur de e-mail, tout serveur de e-mail externe devrait désormais accepter les vôtres. IBM explique ce processus dans l’article du portail de support « Setting Up SMTP (TCP/IP) Mail  » (tinyurl.com/ibmi-smtp1).

—Dan Devoe

Traiter les entiers 64-bit en CL

Q : J’écris un programme CL chargé d’extraire des données dans un message de programme. Mon programme reçoit CPC7061, qui contient un champ *UBIN de huit octets. Comment traiter ce champ en CL ?

R : Depuis la version IBM i 7.1, CL supporte nativement les entiers binaires non signés de huit octets. Pour les versions antérieures, il faut procéder différemment : extraire l’entier de huit octets comme deux champs de quatre octets et les combiner.

Comme CPC7061 est le message que vous essayez d’analyser, la première chose à faire est d’examiner les données champ pour ce message. Faites-le avec la commande suivante :
DSPMSGD CPC7061

Si nécessaire, choisissez l’option 1 (Display message text) pour voir ce que représentent les diverses données champ. Puis choisissez l’option 2 (Display field data).

Quand vous choisissez 1=Display message text, vous voyez
Message . . . . : &4 entries received from journal &1 in &2.
Cause . . . . . : The RCVJRNE command completed.

Quand vous choisissez 2=Display field data, vous voyez
Decimal Vary
Field Data Type Length Positions Length Dump
&1 *CHAR 10 *NO
&2 *CHAR 10 *NO
&3 *BIN 4 *NO
&4 *UBIN 8 *NO

Pour extraire le nombre d’entrées, je commence par examiner le texte du message, et je vois que le nombre d’entrées est représenté par le champ &4. Puis j’examine les données champ, et je vois que &4 est un champ *UBIN de huit octets de long. Comme il est précédé par deux champs de dix octets et un champ de quatre octets, je sais que &4 commence à la position 25 des données du message.

En CL sur IBM i 7.1. Avec la version 7.1, il vous suffit de recouvrir les données du message avec un champ *UINT de huit octets de long. Rappel utile : *UBIN signifie « unsigned binary integer » (entier binaire non signé), identique à TYPE(*UINT) en CL.

DCL VAR(&MSGDTA) TYPE(*CHAR) LEN(32)
DCL VAR(&COUNT ) TYPE(*UINT) LEN(8) +
STG(*DEFINED) DEFVAR(&MSGDTA 25)
DCL VAR(&COUNTR) TYPE(*UINT) LEN(4) +
STG(*DEFINED) DEFVAR(&MSGDTA 29)
DCL VAR(&COUNT) TYPE(*DEC) LEN(15 0)
.
.
RCVMSG MSGID( &MSGID ) MSGF( &MSGF ) +
MSGDTA( &MSGDTA ) RTNTYPE( &RTNTYPE ) +
MSGTYPE( *LAST )

IF (( &RTNTYPE *EQ ’01’ ) *AND ( &MSGID *EQ ‘CPC7061’ )) +
THEN( DO )
CHGVAR &COUNT ((&COUNTL * 4294967296) + &COUNTR)
/* AT THIS POINT, &COUNT CONTAINS THE ENTRY COUNT! */
ENDDO
.
.

Sachez que ce code n’est pas une panacée ! Un entier binaire non signé de huit octets peut stocker jusqu’à 20 digits décimaux. Malheureusement, le langage de programmation CL n’accepte que des nombres de 15 digits. Par conséquent, mon code échouera en présence d’un programme qui traite plus de 999 trillions d’entrées de journal avant de repasser la main à votre programme CL qui lit les données du message. Mais, compte tenu de la limite de 15 digits du langage CL, je n’ai pu faire mieux que 999 trillions.

Pour traiter de plus grands nombres, il vous faudra passer à la 7.1 — ou recourir à un langage qui les accepte, comme RPG.

—Scott Klement