Index
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.
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.
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
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.
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!
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.
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.
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 :
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.
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
Riceviamo e pubblichiamo ben volentieri questo "tip & trick" di Patrick Rizzi che presenta una tecnica che permette di intervenire…
Prendo spunto da una risposta di Michael Mayer sulle mailing list di Midrange.com a chi chiedeva come monitorare i messaggi…
Le imprese sono sempre più alla ricerca di strumenti che possano migliorare l'efficienza, la collaborazione e la gestione delle risorse.…
I primi di Aprile è uscita la "Spring Version" di ACS Access Client Solution, versione 1.1.9.5 Interessanti novità soprattutto in…
Se non vi bastava la ricca agenda delle sessioni del Common Europe Congress 2024, 3-6 Giugno Milano, ecco un altro…
Le funzioni di debug con Visual Studio Code sono disponibili da qualche tempo ma questa nuova versione 2.10.0 semplifica la…
View Comments
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 ...