04 - System Administration04d - IFS04g - Varie sistemistica

QNTC – Accedere a informazioni su server remoti

Introduzione

Il sistema operativo IBM i mette a disposizione il file system IBM i NetClient file system (QNTC) che permette l’accesso a dati ed oggetti memorizzati su server remoti. Opportunamente configurato permette l’accesso a sistemi Windows NT 4.0 o superiori, Linux Samba 3.0 o superiori e versioni supportate di IBM® i NetServer.

Più genericamente tramite QNTC è possibile accedere ad esempio a cartelle di rete condivise, leggere e scrivere file direttamente dal sistema IBM i e in questi casi è possibile ad esempio utilizzare comandi come CPYTOIMPF o CPYFRMIMPF per scrivere o leggere da file di stream e sfruttare le potenzialità del comando o addirittura è possibile utilizzare dei comandi FTP in modo particolare per poter scrivere o leggere direttamente l’indirizzario remoto.

Affinché il server IBM i e il sistema remoto possano dialogare e autenticarsi è necessario conoscere alcune assunzioni e dettagli indispensabili di configurazione. Questo articolo vuole essere un aiuto per cercare di utilizzare al meglio il QNTC evitando alcuni errori comuni che potrebbero far impazzire anche le persone più pazienti o comunque fornire uno spunto risolvere potenziali problemi.

Assunzioni e/o prerequisiti per la configurazione

  1. L’autenticazione fra il sistema IBM i e il sistema remoto avviene tramite lo scambio delle credenziali dell’utente corrente del server IBM i che fa da client
  2. Da QNTC sarà possibile visualizzare solo le cartelle di rete condivise su altri server
  3. Il server remoto dev’essere abilitato a ricevere comunicazioni digitali firmate
  4. QNTC non supporta il concetto di ownership di un file o directory
  5. Se il sistema IBM i non riesce a visualizzare direttamente le cartelle condivise è possibile forzare il nome dei server remoti come indirizzari

Se non avete mai utilizzato QNTC e fate il comando WRKLNK OBJ(‘/QNTC’) e poi premete l’opzione 5 di visualizzazione probabilmente troverete una situazione simile alla seguente:

Per poter accedere alle cartelle di un server remoto conosciuto è necessario far capire al sistema IBM i qual è il server al quale ci si vuole collegare e lo si può fare sia tramite nome host, sia tramite l’indirizzo IP del server. E’ possibile utilizzare il comando :

MKDIR ‘/QNTC/MySERVER’
In questo caso dando per assunto che MySERVER è un server della nostra rete al quale vogliamo accedere (può essere anche l’indirizzo IP), sarà visualizzato in QNTC l’indirizzario appena creato. Se tutto fosse già correttamente configurato, selezionando l’opzione 5 su ‘/QNTC/MySERVER’ saranno visualizzate le risorse di rete condivise.

L’autenticazione fra il sistema IBM i e il sistema remoto

La connessione parte dal sistema IBM i che cerca di autenticarsi su un server remoto con l’utente corrente. Ad esempio tramite il comando :

WRKLNK ‘/QNTC/MySERVER’

Il server IBM i sta richiedendo l’accesso al server MySERVER in base al nome utente e alla password della sessione corrente e in caso positivo visualizzerà le cartelle di rete condivise. Qualora non venisse mostrato nulla e siete sicuri che esistono cartelle di rete condivise, probabilmente l’anomalia può derivare da credenziali errate o da altri potenziali problemi. Con il comando DSPJOBLOG potete analizzare i messaggi ricevuti e individuare altri errori, ad esempio in questo caso si tratta di un codice di errore 5 di classe 1 (la legenda è nella parte successiva del messaggio – “Access Denied”) :

Per potersi autenticare al server è necessario che il nome utente e la password sia in comune comune fra il sistema IBM i e il sistema remoto. A tal proposito vanno fatte delle importanti valutazioni come indicato anche dalla documentazione IBM e di seguito un riassunto di alcuni aspetti rilevanti:

Nel caso che la variabile di sistema QPWDLVL sia impostata a “0” oppure a “1” lo scambio delle credenziali sarà case-insensitive convertendo i caratteri da maiuscoli a minuscoli. Se ad esempio la password su IBM i è PIPPO1234 sarà convertita in pippo1234 che sarà a sua volta utilizzata per l’autenticazione sul server remoto. In tal caso la password sul server remoto dovrà essere impostata a pippo1234 per una corretta autenticazione causa la traduzione implicita da maiuscole a minuscole in fase di autenticazione.

Nel caso che la variabile di sistema QPWDLVL sia impostata a “2” oppure a “3” lo scambio delle credenziali sarà case-sensitive e di conseguenza la password dovrà essere esattamente le stesse nei due sistemi. Di seguito un link per eventuale approfondimento su questo tema :

https://www.ibm.com/support/pages/id-and-password-considerations-qntc-file-system

Visualizzazione delle cartelle condivise

Se l’autenticazione avviene correttamente e non ci sono anomalie, selezionando l’opzione 5 su ‘/QNTC/MySERVER’ saranno mostrate le cartelle condivise del server remoto raggiungibili da IBM i. Le cartelle visualizzate in QNTC saranno le stesse che ad esempio in un server Windows vengono mostrate con l’opzione di condivisione della cartella e saranno raggiungibili all’indirizzario ‘/QNTC/MySERVER/Cartella remota’.

Se ad esempio su un server 192.168.0.1 condividiamo una cartella di nome “transito” e il server IBM i e il server 192.168.0.1 condividono le credenziali di uno stesso utente sarà possibile accedere alla cartella remota tramite il comando WRKLNK ‘/QNTC/192.168.0.1/transito’ e operare di conseguenza con lettura/scrittura di file tramite comandi di sistema o procedure dedicate.

Abilitazione a comunicazioni digitali firmate

Per poter accedere ad un sistema è necessario che il sistema remoto sia abilitato a ricevere comunicazioni digitali firmate.

Questo messaggio è uno dei prerequisiti che viene richiesto ed è indicato anche in caso di anomalie riscontrabili tramite comando DSPJOBLOG.

Nei sistemi un po’ più recenti questo è un prerequisito impostato di default, pertanto in fase di configurazione è meno probabile che si debba intervenire sul server remoto per modificare alcuni parametri di sicurezza che potrebbero inoltre impattare anche su altre applicazioni. Qualora fosse necessario intervenire su questi parametri bisognerà capire in base al sistema operativo del server remoto quali sono le opzioni da modificare e dovrete richiedere qualche aiuto sistemistico!

QNTC non supporta il concetto di ownership di un file o directory

La gestione delle autorizzazioni remote non è possibile dal sistema IBM i ma dovrà essere gestita direttamente sul sistema che ospita la cartella condivisa.

Pertanto non sarà possibile utilizzare comandi che modifichino il livello di autorizzazioni di cartelle e/o file come WRKAUT e CHGAUT.

Forzare nome server come indirizzari su QNTC

In un mondo ideale è possibile sfogliare la rete e trovare i server remoti ai quali QNTC può accedere e di conseguenza, se siete autorizzati, poter visualizzare le cartelle del server remoto.

Personalmente ho riscontrato qualche problema dovuto a potenziali problemi di configurazioni e a tempistiche di scansione e risoluzione della rete e suggerisco di forzare il nome del server remoto sul quale si vuole lavorare come indirizzario su QNTC.

Come indicato in precedenza per accedere a un server remoto è possibile utilizzare il comando MKDIR ‘/QNTC/MySERVER’ indicando in MySERVER il nome host o indirizzo IP al quale vogliamo collegarci e in questo modo il sistema IBM i potrà conoscere in modo “forzato” il nuovo server al quale chiedere di autenticarsi.

E’ importante sottolineare che questa impostazione viene mantenuta fino al prossimo IPL dopodiché sarà persa. Per mantenere queste impostazioni attive a seguito di un IPL bisogna modificare il programma di partenza oppure inserire il comando MKDIR … all’interno di un lavoro a seguito di un IPL.

Una volta fatto il comando da un utente con adeguati privilegi tutti i processi potranno che utilizzano QNTC possono accedere al server “forzato” e non sarà necessario rifare il comando a meno di non cancellare l’indirizzario remoto.

Potenziali problemi con QNTC e risoluzioni

Il problema principale nell’utilizzo del QNTC in assenza di autenticazioni tramite single sign-on consiste nel creare un nuovo utente con relativa password che possa essere condiviso fra il server IBM i e il server remoto al quale si vuole accedere. Il nome utente può essere anche un nome utente locale del server remoto al quale vogliamo accedere senza essere un utente di dominio e questa configurazione può aiutare a risolvere alcuni problemi di configurazione.

Per poter scrivere su una cartella remota condivisa è necessario quindi utilizzare un utente remoto condiviso ma questo vincola diverse applicazioni che magari devono girare con un altro nome utente. Se l’applicazione interessata gira con l’utente USER1 e per scrivere su QNTC utilizziamo solo l’utente WRT_QNTC l’applicazione non riuscirà a scrivere su QNTC perché cercherà di accedere al server remoto con l’utente USER1 che non risulta autenticato.

Per ovviare a questa problematica è possibile intervenire in modi diversi e un po’ creativi, di seguito alcuni esempi :

  • E’ possibile utilizzare il comando SMBJOB sottomettendo il lavoro che deve copiare / trasferire il file con il nuovo nome utente condiviso con il server remoto. Naturalmente questo richiede che l’utente che esegue la SBMJOB con un nuovo nome utente abbia elevati privilegi.
  • E’ possibile effettuare un trasferimento FTP su QNTC loggandosi con il nuovo utente e la password condivisa con il server remoto. Se vogliamo ad esempio trasferire il file “PROVA” presente nella libreria “TEST” su IBM i sul server remoto “192.168.0.1” nella cartella “transito” con il nome “ciaoQNTC.txt” e il nostro server IBM i si chiama “ServerIBMi” potremmo usare un comando FTP simile al seguente:
    • utente / pwd (credenziali del nuovo utente condiviso con server remoto)
    • namefmt 1
    • put ‘/QSYS.LIB/TEST.LIB/PROVA.FILE’ ‘/QNTC/192.168.0.1/transito/ciaoQNTC.txt”
    • quit

Il comando FTP andrà eseguito aprendo una connessione direttamente sul sistema IBM i ad esempio STRTCPFTP RMTSYS(‘ServerIBMi’). In questo modo chiediamo al sistema IBMi di “giocare” con i suoi file system e otterremo il risultato desiderato con i record già troncati all’ultimo valore non blank per ottimizzare anche spazio.

  • E’ possibile delegare l’invio a un altro processo che fa la gestione dei file come mestiere. Ad esempio un programma che vuole trasferire un file potrebbe eseguire un comando da noi creato che per comodità chiamiamo SENDFILE MyFile. Un processo in ascolto continuo, ad esempio una DTAQ temporizzata a un tot di secondi che gira in un sottosistema con il nome utente/pwd condivisa con il server remoto potrebbe prendere in carico la richiesta e centralizzare tutte le richieste ed ovviare al problema dell’utente che esegue il lavoro. Personalmente la ritengo una buona scelta, magari integrando tramite parametrizzazione anche l’opzione di trasferimento tramite FTP del punto precedente all’interno del lavoro in ascolto se richiesto.

Conclusioni

In diverse realtà aziendali spesso ci sono infrastrutture con server eterogenei (Windows / Linux / IBM i …) che hanno la necessità di dialogare scambiandosi file o interagendo fra di loro a seconda delle necessità.

Ci sono diversi modi e tecnologie di risolvere il problema come ad esempio i Web Services o trasferimento di file tramite FTP o SFTP e altre soluzioni.

QNTC permette di fare un’integrazione nativa da IBM i con diversi sistemi remoti e di scambiare informazioni in modo agevole senza fare passaggi ridondanti di trasferimenti di file. Occhio però alla sicurezza in generale, magari cambiare la pwd complessa dell’utente condiviso dopo un periodo di tempo per limitare potenziali problemi…

Per ulteriori informazioni potete consultare la documentazione IBM che riporto di seguito per completezza :

https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_73/ifs/rzaaxqntcfs.htm

About author

Appassionato di informatica, ho iniziato a sviluppare in RPG su piattaforma IBM i (ex AS400). Nel tempo ho potuto approcciare e conoscere diverse tecnologie di sviluppo software, sistemistiche e di sicurezza informatica. Considero la condivisione delle informazioni un motore importante per la crescita in generale e l'apertura all'open source della piattaforma IBM i una grande opportunità di crescita comunitaria

Rispondi

%d blogger hanno fatto clic su Mi Piace per questo: