[RISOLTO] Problema con NewPSDrive

[eritto]

Ciao,

versione di WAPT: 1.3.13.
Server con Debian.
Macchina di sviluppo con Windows 10.

Utilizzo uno script PowerShell in uno dei miei pacchetti. Devo connettermi inizialmente a un'unità di rete e sto usando il comando NewPSDrive.

Questo script funziona perfettamente quando lo eseguo manualmente in una console PowerShell, ma si blocca quando lo eseguo da WAPT.
Il comando è piuttosto semplice:

New-PSDrive -Name Z -Root "\\server.domain.fr\myfolder$" -PSProvider Filesystem.
Tuttavia, quando lo eseguo tramite WAPT, ricevo un messaggio di errore: New-PSDrive: La radice dell'unità specificata "\\server.domain.fr\myfolder$" non esiste o non è una cartella.

Ho cercato di capire le differenze tra l'esecuzione dello script in una console e l'esecuzione tramite WAPT. Ho verificato con una connessione di prova: la condivisione risponde correttamente. Ho anche aggiunto un test che controlla se esiste già un'unità Z: mappata, cosa che non è il caso.

L'unica differenza che noto è quando visualizzo il nome utente: è MyPC\administrator quando lo avvio manualmente, e NT AUTHORITY\System quando viene avviato tramite WAPT. Non so, tuttavia, se il problema possa essere correlato a questo.

Dopo aver pubblicato diversi messaggi sui forum di PowerShell, senza ricevere alcuna risposta finora, ho pensato che forse altri utenti di WAPT abbiano già riscontrato questo problema.

PS: Il file setup.py del pacchetto in questione (anche se non contiene molte informazioni rilevanti):
def install():
print('installazione di cdburnerXP')
run_powershell(r'./cdburn.ps1')

Grazie in anticipo
.

[sfontenau]

Ciao,

Wapt è progettato per non dipendere da fonti esterne (come un'unità di rete).
Infatti, in questo caso, la sicurezza del pacchetto Wapt risulterebbe compromessa. Inoltre, se la rete non è disponibile durante l'installazione, quest'ultima fallirà (ad esempio, durante un WaptExit).
Wapt non è stato progettato per questo.

Perché non includere direttamente il codice sorgente del software nel pacchetto Wapt?

Soprattutto per CDBurner!

Ti incoraggio a rileggere la documentazione sulla creazione dei pacchetti Wapt:
https://www.wapt.fr/fr/doc/CreationPaquets/index.html

[eritto]

Salve,

ho capito a cosa serve WAPT e come usarlo in modalità "normale". Lo sto già facendo e da quel punto di vista funziona tutto bene, non preoccupatevi.
Tuttavia, disponiamo già di un'infrastruttura per l'installazione automatica di software, utilizzata da altri programmi (mdt, ecc.).
La nostra idea è di evitare di dover gestire più repository per ogni aggiornamento.
classico scenario di utilizzo di WAPT. Sospetto che un pacchetto cdburnerxp esista già nei repository di WAPT, ma non soddisfa le nostre esigenze in questo caso.

nel

[dcardon]

Ciao Eric,

Capisco a cosa serve Wapt e come usarlo in modalità "normale". Lo sto già facendo e da questo punto di vista va tutto bene, state tranquilli.
Ma abbiamo già un'infrastruttura per l'installazione automatica del software, utilizzata da altri software (mdt...).

Il modo corretto per integrare WAPT e MDT è quello di impacchettare normalmente nel modo WAPT, installare waptagent alla fine della procedura MDT e chiamare subito dopo un wapt-get install del suo pacchetto macchina.

La nostra idea è di evitare di dover gestire più repository per ogni aggiornamento.
In breve, corrisponde a un'esigenza locale, anche se è vero che non ci troviamo nel classico scenario di utilizzo di WAPT. Sono ben consapevole che un pacchetto cdburnerxp esiste già nei repository di WAPT.

Mi dispiace dirlo così schiettamente, ma è una pessima idea. La disponibilità di una condivisione di rete al momento dell'installazione di WAPT non è garantita (ad esempio, waptexit non lo verifica).

, ma non soddisfa le nostre esigenze, nel caso di questo software.

L'utilizzo di pacchetti WAPT "autonomi" è una condizione essenziale per garantire un tasso di distribuzione di successo...

Per rispondere alla tua domanda specifica (anche se probabilmente ti sto solo aiutando a crearti altri problemi...), l'account utilizzato quando si monta una rete come account LocalSystem (NT Authority\System) è l'account Kerberos del computer (ad esempio, MYCOMPUTER$). Pertanto, è necessario concedere autorizzazioni di lettura al gruppo "computer del dominio" sulla condivisione contenente i programmi di installazione. Questo è un problema puramente di Windows; è strano che nessuno sia stato in grado di rispondere sul tuo forum di PowerShell... (ok, sto solo scherzando un po')

Ma comunque, ripeto, non è proprio una buona idea. Lo ripeto ancora una volta, così non mi si accusa di incoraggiare le persone a farsi del male: non è proprio una buona idea!

Solo perché non abbiamo la soluzione non significa che ti incoraggiamo a creare correttamente i pacchetti WAPT, è solo che se si tratta di avviare uno script PowerShell che deve eseguire un montaggio di rete, in quel caso potresti anche usare i GPO, che daranno altri bug (o altri strumenti di distribuzione che danno altri bug perché seguono lo stesso modello).

Detto questo, se il tuo problema riguarda Python e la creazione di file setup.py per WAPT, hai decine di pacchetti da cui trarre ispirazione. E se vuoi progredire più velocemente e diventare un packager cintura nera di terzo grado in WAPT, Alexandre e Simon offrono una formazione rapida ed efficace!

Denis

[eritto]

Grazie mille per la sua risposta esaustiva.
Ho preso nota di tutto ciò che ha detto sull'utilizzo di WAPT. Stiamo testando le sue funzionalità per capire come integrarlo con le GPO, MDT e il sistema che attualmente utilizziamo per la distribuzione di sistemi e software alle workstation, nonché per gli aggiornamenti.
Dobbiamo procedere gradualmente, poiché non possiamo cambiare tutto in una volta, e sono sorti molti interrogativi.
WAPT sembra promettente, più facile da rendere disponibile ai colleghi rispetto, ad esempio, alla possibilità di creare GPO per tutti.
In breve, siamo nella fase di test e pianificazione per la sua integrazione graduale, sia in parallelo che in sostituzione di alcuni dei nostri strumenti esistenti. L'approccio scelto è quello di integrarlo nell'infrastruttura attuale ed estenderne l'utilizzo in base alle necessità, qualora si dimostri utile o opportuno.
La flessibilità del vostro prodotto lo consente, ed è proprio questo uno dei motivi per cui lo abbiamo scelto.

Grazie ancora per il suo aiuto e per il lavoro svolto su questo strumento
.

[dcardon]

Ciao Eric,

Grazie mille per la sua risposta molto esaustiva.
Ho preso nota di tutto ciò che ha detto sull'utilizzo di WAPT. Stiamo testando le sue funzionalità per capire come potremmo utilizzarlo in relazione a GPO, MDT e al sistema che attualmente utilizziamo per la distribuzione di sistemi e software alle workstation, nonché per gli aggiornamenti.
Dobbiamo procedere gradualmente, poiché non possiamo cambiare tutto in una volta, e ci sono molti interrogativi.
WAPT sembra promettente, più facile da rendere disponibile ai colleghi rispetto, ad esempio, alla possibilità di creare GPO per tutti.
In breve, al momento lo stiamo testando e valutando come integrarlo gradualmente insieme e/o in sostituzione di alcuni dei nostri strumenti esistenti. Il nostro approccio è quello di integrarlo nella nostra infrastruttura attuale ed estenderne l'utilizzo in base alle necessità, se si dimostra utile o opportuno.
La flessibilità del vostro prodotto lo consente, ed è proprio uno dei motivi per cui lo abbiamo scelto.

Se l'obiettivo è semplicemente installare un MSI o un EXE che funzioni correttamente e in modo silenzioso, basta eseguire il seguente comando con il pacchetto, quindi eseguire un caricamento di build (due minuti al massimo per un pacchetto di piccole dimensioni)...

Codice: Seleziona tutto

wapt-get make-template moninstalleur.msi

L'aumento del carico di lavoro derivante dall'esecuzione in parallelo di entrambi i sistemi durante il periodo di test non dovrebbe essere troppo significativo...

Denis

[eritto]

Ciao di nuovo,

grazie per le informazioni.
Anche se non fa parte dell'utilizzo "normale" di WAPT, pubblico qui la soluzione nel caso possa essere utile a qualcuno:
c'era effettivamente un problema di credenziali per l'utente di sistema. La nostra condivisione non richiede autenticazione (è di sola lettura), ma è comunque necessario fornire un nome utente/password, anche se fittizi.

Per quanto riguarda il nostro potenziale metodo di transizione tra il nostro sistema attuale e WAPT, abbiamo validi motivi per procedere in questo modo, che sarebbero troppo lunghi da spiegare qui (e comunque non molto interessanti).

Grazie ancora.
Cordiali saluti,

ET

[dcardon]

Re,

Grazie per le informazioni.
Anche se non fa parte dell'utilizzo "normale" di WAPT, pubblico qui la soluzione, nel caso possa essere utile a qualcuno:
c'era effettivamente un problema di credenziali per l'utente di sistema. La nostra condivisione non richiede autenticazione (è di sola lettura), ma è comunque necessario fornire un nome utente/password, anche se fittizi.

Per quanto riguarda il nostro potenziale metodo di transizione tra il nostro sistema attuale e WAPT, abbiamo buone ragioni per fare le cose in questo modo, che sarebbero troppo lunghe da spiegare qui (e comunque non molto interessanti).

Grazie ancora.
Cordiali saluti,

ET

Mi scuso per l'insistenza, ma per chi leggerà questo post: Non dobbiamo seguire questo esempio!

Se si dispone di una condivisione di rete senza autenticazione, un semplice attacco man-in-the-middle con un po' di spoofing ARP/DNS/NetBIOS reindirizzerà le workstation degli utenti a una condivisione compromessa e tutto ciò che verrà eseguito verrà eseguito tramite un account LocalSystem, bypassando la maggior parte dei controlli di sicurezza standard. In pratica, a meno che non si disponga di protezione 802.1x, pVLAN e da avvelenamento della cache ARP su tutta la rete e non si disponga di laptop, si sta creando un'enorme vulnerabilità di sicurezza che consentirà a qualsiasi script kiddie di prendere il controllo della rete!

Il modello operativo WAPT è valido dal punto di vista della sicurezza. Preferirei che il nome WAPT non fosse associato a tali metodi...

Inoltre, una semplice autenticazione reciproca tramite Kerberos con l'account macchina avrebbe almeno impedito questo attacco MITM. Non sono un esperto di PowerShell, ma un semplice comando "net use" come account LocalSystem consente l'autenticazione e la mappatura di un'unità a una condivisione con permessi di lettura per i "computer di dominio":

Codice: Seleziona tutto

psexec -i -s cmd
    whoami
    net use f:   \\mondomain.lan\sysvol
    dir f:

Sinceramente,

Denis

[eritto]

Ciao di nuovo,

non ho sufficienti conoscenze di rete/hacking per comprendere appieno le implicazioni del tuo commento, ma lo riferirò all'ingegnere che ha implementato questo sistema per sentire cosa ne pensa. Detto questo, abbiamo effettivamente 802.1x, VLAN e tutta una serie di protezioni di rete piuttosto robuste... il che non è un motivo per fare qualsiasi cosa, su questo siamo d'accordo.

In effetti, al momento stiamo "modificando" WAPT per fare cose che non erano state originariamente previste, e capisco che tu preferisca essere molto chiaro.

Per quanto riguarda `net use`, credo di averlo provato e non ha prodotto risultati diversi da `New-PSDrive`, ma eseguirò di nuovo il test prima o poi (anche se fondamentalmente, se ho capito bene, non cambia molto per quanto riguarda il problema di sicurezza menzionato).

Cordiali saluti,
ET