NetServer per tutti – parte 5

Come risolvere i problemi più comuni

In questo quinto articolo su NetServer per IBM i cerchiamo di affrontare i problemi più comuni che possono capitare e indicare possibili soluzioni.

Talvolta l’accesso alle risorse condivise di IBM i tramite NetServer procura fastidiosi grattacapi.
Da una parte abbiamo la parte server (ovvero IBM i) con la sua evoluzione tecnologica e il susseguirsi di sistemi operativi (siamo giunti alla 7.5) e dall’altra una costellazione di client con un’altrettanta varietà di versioni di sistemi operativi e di service pack. Tutto ciò moltiplica esponenzialmente le combinazioni di convivenza di client e server diversi. A tutto ciò aggiungete le problematiche di configurazione di firewall e/o router nel caso in cui il server si trovi su una rete remota rispetto al client.

Penso che questa serie di articoli possa essere utile e comoda per avere un “bigino” che compendi tutte le informazioni necessarie alla configurazione di NetServer lato server e lato client e una panoramica delle più frequenti situazioni di problemi di connessione. Entrambi i sistemi operativi (server e client) sono in continua evoluzione, quindi questa mini-guida non potrà essere esaustiva, ma mi auguro possa esservi di aiuto in molte delle situazioni che incontrerete nella vostra attività quotidiana.
Articoli precedenti:

• configurare il servizio
• condividere le risorse di IFS
• gestire NetServer da riga comandi con i NetTools
• accedere alle risorse condivise

Profilo disabilitato per NetServer

Bisogna porre particolare attenzione al caso in cui il profilo risulti disabilitato per il servizio NetServer. Se un utente supera il numero massimo di tentativi di collegamento (specificato nel valore di sistema QMAXSIGN) il profilo viene disabilitato per il servizio NetServer.

Quando un profilo viene disabilitato viene inviato il messaggio CPIB682 alla coda messaggi QSYSOPR

Un profilo in stato *ENABLED per il sistema operativo
potrebbe trovarsi in stato *DISABLED per il solo servizio NetServer

In passato era possibile riabilitare un profilo per NetServer tramite il comando CHGUSRPRF USRPRF(nome-profilo). NetServer usava la data di ultima modifica del profilo per determinare se era stato cambiato dopo la disabilitazione. Se la data di modifica era più recente della data della disabilitazione il profilo veniva riabilitato per NetServer.
Questo metodo in presenza di PTF specifiche non riabilita l’utente per il servizio NetServer. Le PTF per ogni release che tolgono la funzionalità al comando CHGUSRPRF di riabilitare il profilo per NetServer sono: V5R4M0: MF55657 / V5R4M5: MF55658 / V6R1M0: MF55659 / V6R1M1: MF55660 / V7R1M0: MF55661 e in tutte le release a partire da 7.2

Ultima possibilità un po’ più drastica: riavviando il servizio NetServer tutti i profili disabilitati vengono riabilitati.

Per controllare quali utenti sono in stato disabilitato per NetServer ci può venire in aiuto anche il servizio SQL USER_INFO:

select USER_DEFAULT_PASSWORD, AUTHORIZATION_NAME "Utente", TEXT_DESCRIPTION "Descrizione", PREVIOUS_SIGNON "Ult.collegamento 5250", SIGN_ON_ATTEMPTS_NOT_VALID "Coll.non validi", STATUS "Stato", PASSWORD_CHANGE_DATE "Data/Ora mod.pwd", DAYS_UNTIL_PASSWORD_EXPIRES "gg a scadenza password", 
    SET_PASSWORD_TO_EXPIRE "Pwd a scad.", HOME_DIRECTORY "Indirizzario corrente", NETSERVER_DISABLED
  from USER_INFO
  where NETSERVER_DISABLED = 'YES'
  order by AUTHORIZATION_NAME;

Accesso problematico alle risorse condivise del file system QDLS

Premesso che il file system QDLS andrebbe usato il meno possibile o per nulla, si potrebbe comunque avere la necessità di accedere ad alcune delle sue cartelle.
Molto probabilmente lo stesso client può avere la necessità di accedere sia a risorse della QDLS sia di altri file system. Questa convivenza non è sempre facile.

Il motivo risiede nella caratteristica threadsafe dei file system. Il tutto è spiegato in dettaglio nel documento IBM “IBM i NetServer Threaded Request Support“.

Da V5R4 quando un client accede a una risorsa condivisa di NetServer il sistema per default cerca di gestire la risorsa in un job multithread (QZLSFILET), ovvero un solo lavoro può soddisfare le richieste di tanti client diversi.
Quindi se accedendo al server IBM i la prima risorsa a cui si cerca di accedere appartiene a un file system threadsafe la richiesta del client viene indirizzata al job QZLSFILET; se dallo stesso client successivamente si tenta di accedere a una risorsa appartenente a un file system non threadsafe (p.es. la QDLS) il sistema risponde con un errore generico o una continua richiesta di credenziali di accesso. Il problema consiste nel fatto che il job QZLSFILET (multithread) non può gestire l’accesso a una risorsa non-threadsafe.
Il problema (dal lato client) si può bypassare accedendo per primo alla risorsa condivisa non-threadsafe (ovvero la QDLS) e successivamente alle altre risorse, così che la richiesta del client venga indirizzata al job QZLSFILE.
Se l’utilizzo delle risorse condivise del file system QDLS insieme a risorse del file system root creano continuamente problemi si può prendere in considerazione (per quanto sconsigliato) la possibilità di disabilitare il job di preavvio multithread QZLSFILET. Il documento tecnico IBM “Disabling and Re-Enabling the Use of the Threaded QZLSFILET NetServer Job” (rif. 643625) spiega come disabilitare il job QZLSFILET.

NetServer non si avvia

Avviando NetServer con il comando STRTCPSVR *NETSVR anche in caso di fallimento dell’avvio del servizio non riceverete un messaggio di escape dall’esecuzione del comando. Occorre verificare da Navigator for i che il servizio sia attivo. Oppure controllare nella coda messaggi QSYSOPR che sia presente il messaggio di corretto avvio. In caso di insuccesso invece troverete il messaggio con codice CPIB683 che può già fornirci una prima indicazione del problema.

Cold restart

Dopo aver verificato la corretta configurazione del servizio (cfr. il primo articolo al cap. “Configurare NetServer”) si può tentare un “cold restart” (riavvio a freddo) del servizio. Per i vari servizi TCP esiste generalmente una procedura documentata per un cold restart. A differenza di un normale riavvio, il cold restart cerca di terminare e resettare lo stato del servizio come se in precedenza non fosse stato avviato ovvero come se ci si trovasse subito dopo un IPL. Nel caso del servizio NetServer la procedura è la seguente:

1. CHGPJE SBSD(LIBL/QSERVER) PGM(QZLSFILE) STRJOBS(NO)
2. ENDPJ SBS(QSERVER) PGM(QZLSFILE) OPTION(*IMMED)
3. CALL QZLSENDS PARM(x'00000000')
4. CALL QZLSSTRS PARM('1' x'00000000')
   Se il servizio parte con successo eseguire:
5. CHGPJE SBSD(LIBL/QSERVER) PGM(QZLSFILE) STRJOBS(YES)
6. STRPJ SBS(QSERVER) PGM(QZLSFILE)

Firewall

Il servizio NetServer utilizzate le porte TCP 137, 138 e 139 (NetBios) e 445 (CIFS). Quindi nel caso in cui il server si trovi su una rete remota rispetto al client protetta tramite firewall, bisogna assicurarsi che il traffico di rete su quelle porte sia consentito.

Bibliografia

La pagina principale della documentazione IBM su NetServer è consultabile a questo link: https://www.ibm.com/docs/en/i/7.5?topic=services-i-netserver. Altre risorse utili le trovate nel documento allegato:

Nel prossimo articolo parleremo di come controllare gli accessi a NetServer.