Archivio

Archivio per la categoria ‘NetWorking’

Mikrotik RouterOS Upgrade dalla versione 6 alla 7

20 Febbraio 2023 Commenti chiusi

Rapida guida per aggiornare un sistema Mikrotik dalla RouterOS 6 alla 7 , sia package che bootloader. Il tutto è possibile tramite riga di comando, quindi possiamo collegarci in ssh o tramite il tool Winbox ed aprire una finestra terminal.

Prima di tutto, un backup della configurazione corrente non è una cattiva idea, system backup save name=%NOME_FILE_BACKUP% e scarichiamolo dalla routerboard.

Procediamo…

Identifichiamo la versione package tramite il comando system package update print

Identifichiamo la versione del firmware (bootloader) con il comando system routerboard print

Cambiamo il channel degli aggiornamenti con il comando system package update set channel=upgrade

Possiamo controllare la disponibilità di upgrade tramite il comando system package update print

Possiamo quindi procedere all’installazione con il comando system package update install

  • il comando avvia il download ed installazione con successivo reboot senza chiedere ulteriore conferma.

Al riavvio, un controllo che l’aggiornamento sia stato applicato sempre con il comando già usato sopra system package update print

Reimpostiamo il channel con il comando system package update set channel=stable

Controlliamo la presenza di aggiornamenti con il comando system package update print

Ora procediamo con l’aggiornamento del firware e allineiamolo alla stessa versione dei packages 

Controllo della versione corrente system routerboard print

Procediamo all’aggiornamento system routerboard upgrade , il comando richiede la conferma per procedere

Eseguiamo il reboot, in questo passaggio il reboot non è automatico, system reboot

A reboot ultimato un ultimo controllo system routerboard print

Aggiornamento completato. Il tutto volendo può essere scriptato qualora si abbia necessità di distribuirlo su molteplice apparati senza una vera e propria gestione centralizzata.

Categorie:NetWorking, Sistemista@Work Tag:

Ticket Kerberos, durata e disconnessione dal server

23 Novembre 2011 Commenti chiusi

Successivamente ad una migrazione d Windows 2003R2 a Windows 2008  mi viene segnalato un problema abbastanza anomalo, ad un certo punto viene persa la connessione delle unità mappata, programmi che hanno i file aperti verso il server (doc, xls ecc…) devono essere terminati o richiedono il salvataggio in altro percorso.

Dalle verifiche emerge che tentando di ristabilire le connessioni verso il server è richiesta l’autenticazione, riavviando il client tutto torna normale. All’inizio quello che sembrava un problema sporadico mostra un proprio schema e cioè il problema si manifesta ad un intervallo di tempo ben preciso dall’ultimo login, la causa: scadenza del Ticket Kerbero rilasciato al momento del login

Prosegui la lettura…

Migrazione server Windows DHCP

1 Novembre 2011 Commenti chiusi

Qualora si usasse un server Windows come server DHCP potrebbero verificarsi casi in cui sia necessaria o magari utile migrare la configurazione ed il database di tale funzione, magari a seguito di sostituzione di un domain controller, o più semplicemente perchè si vuole demandare tale compito ad altra macchina, dalle KB di Microsoft vediamo come possa essere possibile fare cioò senza dover riconfigurare tutti i parametri precedentemente immessi.

La KB in  questione è 325473 , vi rimandiamo al link per la consultazione, illustra come trasferire il DHCP da un’origine Windows Server NT/2000/2003 ad un server Windows 2003, qui invece una breve guida su come trasferire in pochi passaggi il database da un Server 2003 ad un’altro.

Inoltre vi segnaliamo  la documentazione Technet relativa al server DHCP di Windows 2003.

Fedora – Network configuration

24 Ottobre 2011 Commenti chiusi

Fedora – Network configuration, Fonte openskill.info

Fonte openskill.info

Network configuration on Fedora is quite similar to the one for other versions of RedHat Linux, besides the standard files, the main configuration is done on /etc/sysconfig/network where is defined the hostname and can be placed the default gateway and in the files of the /etc/sysconfig/network-scripts/ directory.

The TCP/IP network setup is done with the script /etc/init.d/network, with obviously must be started before other network services on a connected machine.
The official graphical configuration tool is system-config-network (Menu System Settings – Network), from here is possible to define the IP parameters for all the interfaces found on the system (tab Devices, modifies the /etc/sysconfig/network-scripts/ifcfg-interface and /etc/sysconfig/networking/devices/ifcfg-interface files), the IP of the DNS servers (tab DNS, modifies /etc/resolv.conf), the static host IP assignement (tab Hosts, modifies /etc/hosts).
Fedora supports also user’s profiles, with differnet network settings. The Network Configuration tools easily let the user define a profile and its parameters, the relevant system files are placed in the directory /etc/sysconfig/networking/profiles/profilename/. Currently Fedora does not allow the definition of a profile at boot time, when the machine is started the default “Common” profile is used, to switch to a custom one either launch system-config-network graphical tool and select your profile or type system-config-network-cmd -p profilename –activate.
RedHat provides other network configuration tools:
netconfig is an old text configuration tool, which is obsolete and may be used to a fast configuration;
system-config-network-tui is the text version of the graphical Network Configuration Tool.
system-config-network-druid (Menu System tools – Internet configuration wizard) is a guided wizard which helps an easy configuration of Ethernet, modem, ISDN, DSL, wireless configuration.

Firewall configuration
Red Hat stores the firewall configuration in the /etc/sysconfig/iptables file which is formatted in order to be used by the iptables-restore command. Firewalling is managed with the /etc/init.d/iptables script which can be followed by arguments like start to activate firewalling, stop to disable it, panic to shutdown any Internet access, status to view the current iptables rules.
A simple and not extremely flexible configuration tool is system-config-firewall, which is adeguate for a desktop machine but surely not for a router/firewall.

Integrare Linux in un dominio WinNT/2000 con Winbind

24 Ottobre 2011 Commenti chiusi

Articolo tratto da OpenSkills.info adatto a scenari d’integrazione Linux in domini Windows. L’articolo originale è disponibile qui

Articolo di Fulvio Ferroni
adattato per OS.
https://didattica.swlibero.org/docs/linuxmagazine/ferroni24.html

In questo articolo voglio affrontare una problematica un po’ particolare ma secondo me molto interessante: l’integrazione di una macchina Linux (ovviamente equipaggiata con Samba) in un dominio NT o in una active directory Windows 2000 grazie all’utilizzo di Winbind.
Per integrazione qui intendo l’eventualità che la macchina Linux entri a far parte effettivamente del dominio o della active directory ma anche e soprattutto che l’autenticazione degli utenti Linux (attenzione: utenti Linux, non utenti Samba) avvenga presso il Primary Domain Controller Windows.
Credo che questa possibilità sia molto interessante in quelle situazioni in cui si voglia introdurre Linux in un ambiente di rete già consolidato su piattaforma Windows, senza dover essere costretti a ridefinire tutti gli utenti nel nuovo ambiente.
Il contesto cui faccio riferimento è una rete scolastica, visto che è nelle scuole che svolgo la mia attività professionale, ma la soluzione prospettata può essere validamente attuata anche in altri ambienti.
Immagino già le obiezioni dei “puristi” circa l’opportunità di “convivere con il nemico” anziché sostituire i prodotti proprietari con software libero, da preferire per i motivi etici, filosofici, didattici, economici già più volte illustrati nelle pagine di questa rivista; il fatto è che molte volte questo non è possibile, o almeno non “subito”. In certi casi è necessario almeno un periodo di “affiancamento” nel quale introdurre gradualmente Linux ed il software libero anche per permettere che nel frattempo si formi e si diffonda una “cultura” sufficiente per l’uso proficuo e la gestione di questi strumenti.
La procedura qui esposta è stata usata su una RedHat 7.3 ma è applicabile anche su altre distribuzioni.
Dalla versione 8.0 RedHat permette di configurare il login su un dominio NT direttamente tramite il comando custom authconfig, rendendo queste operazioni decisamente più semplici.

CONFIGURARE GLI STRUMENTI NECESSARI
Winbind è un nuovo software entrato a far parte dell’insieme degli strumenti della suite Samba dalla versione 2.2.2 ed è contenuto nel pacchetto rpm samba-common. Ne fanno parte 2 librerie per il Name Service Switch (nsswitch) e il Pluggable Authentication Modules (PAM), un programma di utilità, wbinfo ed un demone, winbindd, che permettono agli utenti di accedere alla macchina Linux (e a quei servizi che prevedono l’autenticazione PAM) usando le informazioni di account già presenti in un Domain Controller Windows.
Più in dettaglio winbindd fornisce informazioni su utenti e gruppi NT a nsswitch che è un servizio presente ormai in tutte le moderne librerie C e che permette di ottenere i dati relativi ad utenti, gruppi ed host da vari tipi di fonti diverse (NIS, DNS e adesso anche Winbind); il servizio di autenticazione viene invece garantito dalla presenza di un apposito modulo PAM.
Vediamo le operazioni da compiere per raggiungere il risultato voluto (le prove sono state fatte su una macchina Linux con RedHat 7.3, Samba 2.2.3, inserita in una rete gestita da un PDC NT 4.0 denominato ANDREA:

1) Modifiche a smb.conf
Nel file di configurazione di Samba /etc/samba/smb.conf, inserire nella sezione [global] le seguenti direttive:
; nome del dominio NT
workgroup name = PALLADIO
; gestione password criptate
encrypt password = yes
; impostazioni sul server PDC
security = domain
password server = *
; impostazioni per il demone winbindd
winbind separator = +
winbind uid = 10000-20000
winbind gid = 10000-20000
winbind enum users = yes
winbind enum groups = yes
template shell = /bin/bash
template homedir = /home/%D/%U

Qualche commento sulle opzioni che permettono di configurare il demone winbindd:
con winbind separator si imposta il carattere con cui si combinano nome di dominio e nome utente NT in modo da formare il nome utente Linux; è consigliato scegliere un carattere diverso da quello di default “\” che può dare problemi in quanto ha un significato speciale nella shell; la scelta del carattere “+” dovrebbe essere la migliore.
winbind uid e winbind gid permettono di impostare i range di ID utenti e gruppi che winbind utilizza per “rimappare” gli utenti e gruppi windows in utenti e gruppi Linux.
winbind enum users e winbind enum groups permettono di attivare l’enumerazione di gruppi e utenti.
template shell e template homedir permettono di definire rispettivamente la shell e la home directory degli utenti; si noti l’uso delle “variabili samba” %D = nome dominio NT e %U = nome utente NT (nel caso in esame l’utente PALLADIO+pippo avrà come home directory /home/PALLADIO/pippo).

2) Modifiche a nsswitch.conf
Nel file /etc/nsswitch.conf, contenente la configurazione del servizio nsswitch, occorre aggiungere winbind tra le sorgenti dei dati riguardanti utenti e gruppi.
Quindi le relative righe, che solitamente appaiono nel seguente modo:
passwd: files
group: files
devono divenire:
passwd: files winbind
group: files winbind

L’ordine con cui vengono elencate le fonti è significativo e in questo caso viene opportunamente lasciata la priorità nel reperimento delle informazioni ai file di sistema (passwd e group).

3) Modifiche ai file di configurazione del PAM
Questa è la fase più delicata e “pericolosa”: operazioni maldestre compiute sui file di configurazione contenuti in /etc/pam.d/, possono condurre all’impossibilità di effettuare il login o a permettere a tutti di entrare senza password o ad altri inconvenienti simili. E’ quindi opportuna una copia dei file che ci si accinge a modificare ed è anche consigliabile tenersi aperta una task di riserva come “root” in modo da poter tornare sui propri passi in caso i test non diano esiti positivi.
Sarebbe inoltre opportuno un approfondimento circa l’uso del PAM che è uno strumento molto versatile e potente ma che non è possibile effettuare in questa sede.
Vediamo quindi solo le modifiche che ho apportato nell’ambito delle mie prove:
nel file /etc/pam.d/system-auth ho aggiunto la riga
auth sufficient /usr/lib/security/pam_winbind.so
dopo la prima riga auth già presente e ho trasformata la riga
auth sufficient /lib/security/pam_unix.so likeauth nullok
in
auth sufficient /lib/security/pam_unix.so likeauth nullok use_first_pass
nel file /etc/pam.d/login ho aggiunto le seguenti due righe, rispettivamente come prima riga account e come ultima riga session required:
account sufficient /lib/security/pam_winbind.so
session required /lib/security/pam_mkhomedir.so skel=/etc/skel/ umask=0022

In particolare l’ultima è molto interessante in quanto fa si che venga creata automaticamente la home directory dell’utente nel momento in cui questo si collega per la prima volta alla macchina Linux; facendo riferimento alle impostazioni illustrate in precedenza, nel momento in cui si collega l’utente PALLADIO+pippo viene creata la sua home directory /home/PALLADIO/pippo (questo naturalmente se e solo se la directory /home/PALLADIO già esiste).
Un’ultima osservazione circa la modifica al file system-auth; essendo la sua configurazione usata in molti altri file di configurazione di PAM (e non solo in login) attraverso il modulo pam_stack, può essere una buona idea lasciarlo inalterato, copiarlo e modificare la copia nominandola ad esempio system-auth-winbind. Ovviamente i riferimenti al file system-auth contenuti nel file login dovranno essere opportunamente modificati.

4) Attivazione e test
Occorre prima di tutto inserire la macchina Linux nel dominio NT agendo sul server NT con il Server Manager ed eseguendo su Linux il seguente comando:
smbpasswd -j PALLADIO -r ANDREA -U Administrator
Se tutto va bene dopo aver digitato la password (che Administrator ha su NT) si ottiene il messaggio:
Joined domain PALLADIO
A questo punto si possono attivare i servizi smb e winbind e testare il buon funzionamento di quest’ultimo con i comandi
wbinfo -u
wbinfo -g

per ottenere rispettivamente l’elenco degli utenti e dei gruppi del dominio.
E’ anche possibile avere un elenco di tutti gli utenti e gruppi sia quelli del dominio che quelli “nativi” di Linux con i comandi:
getent passwd
getent group

Infine si può procedere alla prova più importante cioè quella di accreditamento sulla macchina Linux di un utente già esistente nel dominio NT; al login si scrive il nome utente secondo la sintassi stabilita (nel nostro caso “PALLADIO+pippo” ) e la password di quell’utente nel dominio NT.
Nel mio caso, al login appare un messaggio di errore: “[: too many arguments” abbastanza misterioso; non sono riuscito a stabilirne l’origine anche dopo ricerche in Internet, comunque non influisce in alcun modo sul buon esito delle operazioni effettuate dall’utente.
E’ anche possibile ottenere l’accreditamento degli utenti per altri tipi di servizi a patto che questi abbiano il supporto per il PAM; ad esempio nella macchina oggetto delle prove era attivo il login grafico con gdm e per ottenere che il meccanismo funzionasse anche in questa modalità è stato necessario aggiungere al file /etc/pam.d/gdm la linea:
session required /lib/security/pam_mkhomedir.so skel=/etc/skel/ umask=0022

CONCLUSIONI
Grazie all’uso di Winbind in associazione con gli altri strumenti di Samba gli amministratori di rete hanno la possibilità di far convivere piattaforme diverse sfruttando il data base di utenti e gruppi definito in un preesistente ambiente Windows.
Questa è una ulteriore conferma della bontà della scelta di GNU/Linux, e del software libero in generale, a livello di “apertura” e di possibilità di integrazione tra ambienti diversi. E’ inoltre una conferma dell’attenzione che gli sviluppatori di questi programmi dedicano a tali argomenti e del grande vantaggio che in questo settore il software libero ha nei confronti di molto software proprietario che molto spesso è caratterizzato da soluzioni chiuse se non addirittura “blindate”.