Last Updated on 28 Luglio 2020 by Roberto De Pedrini
Index
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
- 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
- Da QNTC sarà possibile visualizzare solo le cartelle di rete condivise su altri server
- Il server remoto dev’essere abilitato a ricevere comunicazioni digitali firmate
- QNTC non supporta il concetto di ownership di un file o directory
- 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
Credo che a tutti noi che operiamo in ambito IBM i sia successo, e continui a succedere, di avere una Read more
I virus e in generale i malware come i ransomware possono fare danni anche all'IBM i se trovano directory condivise Read more
I numerosi servizi del DB2 for i si arricchiscono di una nuova categoria, con cui si può "curiosare" nell'IFS direttamente Read more
FAQ, trucchi e howto sulla System Administration di IBM i: check oggetti in blocco, RGZPFM furbo, whatsmyip per IBM i,DNS Read more
Rimane il problema di non poter accedere ad un server MS con utenti di dominio. Nel mio caso, dovrei inviare un nome utente con dominio annesso, es. nomeDominio/as400user . Al momento, è questo che mi ferma.
Altro problema: dando il nome del server (es. nomeserver.company.net) può capitare di superare la lunghezza massima del nome di una sottodirectory. Facile workaround , dare il nome della subdirectory com l’indirizzo ip (10.21.3.5), ma poco elegante in quanto si salta l’intermediazione del DNS.
Sono due casistiche che ho riscontrato anche io e guardando la documentazione IBM non ho trovato una soluzione adeguata.
Se la macchina IBMi è configurata con lo stesso dominio di AD (Active Directory) l’autenticazione nomeDomino/as400user è implicita e funziona ma solo a condizione che ci siano le stesse credenziali (in base al QPWDLVL) fra IBMi e AD, ma se ci fossero più domini di autenticazione il problema rimane.
Probabilmente con dominio impostato e un single sign-on configurato su IBMi mi aspetto che l’autenticazione funzioni e comunque non risolverebbe il problema perchè non permetterebbe di specificare in modo esplicito la mappatura nomeDominio/as400user
Personalmente penso che l’autenticazione non esplicita sia un limite non facilmente aggirabile
Sulla lunghezza del nome del server condivido che è poco elegante ma è una soluzione …