Programmi, Program Files e Program Files (x86): un po’ di chiarezza

All’interno di Windows 10, la cartella C:\Program Files\ è visibile con questo nome solo accedendo tramite prompt dei comandi. Infatti, se proviamo a visualizzare la struttura di cartella tramite Esplora file, vedremo, al di sotto della radice, due cartelle simili che hanno a che fare con i programmi e la loro installazione: C:\Programmi e C:\Programmi (x86).

Il motivo di questa organizzazione è dato dal fatto che quello che vediamo tramite Esplora file è una localizzazione, ovvero la traduzione nella lingua del sistema operativo, ad esempio l’italiano, rispetto al nome reale delle cartelle.

In ogni caso, la cartella visibile come C:\Programmi corrisponde, come detto, alla cartella reale C:\Program Files. Tale cartella, nei sistemi a 64 bit, ormai la quasi totalità, contiene le installazioni degli applicativi, appunto a 64 bit. Invece, la cartella visibile come C:\Programmi (x86) corrisponde alla cartella reale C:\Program Files (x86) nella quale vengono installate le versioni a 32 bit dei vari programmi di cui si effettua il setup (installazione).

Le applicazioni scritte per l’ambiente a 64 bit vengono eseguite in maniera normale, tecnicamente di dice nativa, mentre quelle a 32 bit vengono emulate nell’ambito di un processo di nome WOW64 (Win32 On Win64).

Carlo A. Mazzone

 

Supportaci condividendo sui social il nostro articolo!

Sottoprogrammi e programmazione procedurale in un file batch

Uno degli approcci più classici nello sviluppo software è quello che prende il nome di programmazione procedurale. In buon sostanza di tratta della pratica di suddividere il programma principale  in parti più piccole, note con il termine di sottoprogrammi (in inglese subroutine) ma anche procedure o funzioni a seconda dei diversi linguaggi di programmazione. Tutto ciò per facilitare la stesura e la manutenzione del programma stesso. Dopo questa introduzione sui sottoprogrammi dareste per scontato la loro disponibilità nei file batch. Ebbene, sbagliereste, in quanto tale possibilità non è contemplata nei file batch. Tuttavia, una possibilità di emulare tale comportamento è comunque possibile individuarla, innanzitutto nell’utilizzo del comando CALL che consente di richiamare un altro file batch. Supponiamo allora di avere un file batch di esempio che serve solo a produrre un messaggio a video:

 

@ECHO OFF

REM File saluta.bat

ECHO Salve a tutti

 

Chiameremo il file, come visibile nel commento precedente, saluta.bat.

Il nostro file principale non dovrà far altro che richiamare, con il comando CALL, il file che funge da sottoprogramma, così come mostrato di seguito.

 

@ECHO OFF

REM Sottoprogrammi

ECHO Io sono il file principale

CALL saluta.bat

ECHO Sono ancora il file principale

 

Banalmente, il risultato a video sarà il seguente:

 

Io sono il file principale

Salve a tutti

Sono ancora il file principale

 

Intuitivamente, si capisce come il relegare un dato comportamento in un file che funge da sottoprogramma consente di snellire e modularizzare il proprio codice in quanto sarà possibile registrare in un dato file batch un certo blocco di istruzioni da far ripetere anche più volte all’interno del nostro programma principale.

Tuttavia, oltre a quello mostrato, esiste un altro modo per inserire una sorta di sottoprogramma direttamente nel file batch. Tale approccio sfrutta il concetto di etichetta. Una etichetta (label in inglese) è una stringa di testo, da terminarsi con il simbolo dei due punti, che viene posizionata in una riga qualsiasi del file batch e che può così essere considerata un punto di salto per l’esecuzione del comando GOTO. Di seguito subito un esempio:

 

@ECHO OFF

:ritorno

CLS

TIME /T

GOTO ritorno

 

Nel  codice proposto, potete notare un’etichetta di nome ritorno subito dopo della quale viene invocato il comando CLS seguito da TIME che visualizza la data corrente del sistema e che grazie all’opzione /T non ne chiede l’impostazione. L’ultima istruzione è GOTO ritorno che forza l’esecuzione a riprendere proprio dal punto etichettato come ritorno creando quindi un loop (nome tecnico per indicare un ciclo), in questo caso infinito. Per interrompere l’esecuzione sarà necessario usare la combinazione di tasti CTRL+C. Una particolarità relativa alle etichette è che Il comando GOTO accetta l’etichetta speciale di destinazione :EOF, che trasferisce il controllo alla fine del file batch corrente. Ciò consente di uscire da uno script senza definire un’etichetta specifica. Credo sia inutile sottolineare che il precedente è un programma assolutamente stupido e realizzato al solo scopo di presentare un esempio di facile comprensione relativo al comando GOTO. Tuttavia, abbiamo ora uno strumento in più che ci consente di rendere i nostri script maggiormente interattivi. Per dimostrarlo supponiamo di voler realizzare una piccola utility (ovvero un programma di utilità) che consenta all’utente di selezionare un certo comando informativo sullo stato del sistema. Vi scrivo di seguito il codice che commentiamo subito dopo.

 

@ECHO OFF

:menu

CLS

ECHO ****************************************************

ECHO *            VERIFICA RETE

ECHO *

ECHO *  1. VISUALIZZA IMPOSTAZIONI DI RETE

ECHO *  2. TEST CONNESSIONE RETE LOCALE

ECHO *  3. TEST CONNESSIONE INTERNET

ECHO *

ECHO *  Q. Esce e torna al prompt dei comandi

ECHO ****************************************************

 

SET GW=192.168.1.1

SET /P scelta=SCEGLI:

 

IF %scelta%==1 GOTO ipconfig

IF %scelta%==2 GOTO gateway

IF %scelta%==3 GOTO internet

 

IF %scelta%==Q GOTO :EOF

IF %scelta%==q GOTO :EOF

 

:ipconfig

ECHO Rileviamo le configurazioni delle schede di rete

IPCONFIG /ALL

PAUSE

GOTO menu

 

:gateway

ECHO Eseguiamo un ping al default gateway

PING %GW%

PAUSE

GOTO menu

 

:internet

ECHO Test connessione Internet

PING 8.8.8.8

PAUSE

GOTO menu

 

La prima parte dello script è assolutamente banale. Con una serie di comandi ECHO mostriamo a video un menu con tre classiche possibilità per fare il cosiddetto troubleshooting, ovvero individuazione ed eliminazione di un problema, della nostra connessione di rete. Vi faccio tuttavia notare come abbia posto, in testa allo script, un’etichetta, :menu, che servirà come punto di richiamo per far visualizzare il menu alla fine di ogni comando. Successivamente, al fine di rendere più gestibile lo script, dichiariamo, la seguente variabile di ambiente:

 

SET GW=192.168.1.1

 

Tale variabile GW contiene uno dei classici default gateway. Con tale termine si indica l’indirizzo IP che viene utilizzato per uscire dalla nostra rete locale. Di norma esso è l’indirizzo del router ADSL della nostra connessione ad Internet. Nel caso in cui tale IP dovesse risultare diverso da quello impostato per la nostra specifica macchina sarà sufficiente modificarlo di conseguenza. L’istruzione successiva:

 

SET /P scelta=SCEGLI:

 

visualizza il messaggio “SCEGLI:” e memorizza la digitazione dell’utente in una variabile dal quasi scontato nome scelta. Tale variabile verrà testata con una serie di IF per individuare la selezione effettuata dall’utente. Ognuna di tali scelte termina nel codice con i comandi:

 

PAUSE

GOTO menu

 

che consentono appunto, dopo una pausa di visualizzazione, il ritorno ai comandi ECHO che ripropongo a video il menu con le scelte possibili. Per chi è abituato a smanettare con i comandi di rete, IPCONFIG e PING sono pane quotidiano. Nello specifico, IPCONFIG, che aveva già visto in precedenza, con l’opzione /ALL, visualizza in dettaglio tutte le informazioni sulla configurazione della macchina in uso. Il comando PING, invece, serve per capire se la nostra scheda di rete riesce a comunicare, in gergo tecnico pingare l’indirizzo IP che specifichiamo come argomento del comando in questione. Nel caso dell’etichetta :gateway “pinghiamo” il gateway di default. Se questo dovesse essere diverso da 192.168.1.1 lo potremmo scoprire proprio con il comando IPCONFIG e quindi modificheremmo la variabile di ambiente GW di conseguenza. Nel caso, invece, dell’etichetta :internet effettuiamo il ping  con l’IP 8.8.8.8. Tale IP corrisponde ad un server DNS di Google e quindi è sempre attivo su Internet. Ovviamente potremmo utilizzare un IP pubblico qualsiasi che sappiamo essere sempre in linea al fine di verificare la nostra connessione verso l’esterno. Per inciso, un server DNS è una macchina che consente la traduzione, nota come risoluzione, dall’indirizzo IP al nome di dominio del tipo www.exaple.com e viceversa.

 

Carlo A. Mazzone

Supportaci condividendo sui social il nostro articolo!

Linux e Windows 10: la shell Bash

Oltre alla soluzione che prevede l’installazione di Cygwin  (https://www.cygwin.com/) come ambiente di emulazione per Linux, per i sistemi Windows 10 esiste un’alternativa che prevede l’installazione della shell bash come applicativo nativo di Windows stesso. La bash su Windows fornisce così agli sviluppatori e sistemisti una shell Linux in  cui eseguire la maggior parte dei comandi Linux senza dover installare uno specifico emulatore esterno. Il prerequisito fondamentale per l’installazione di tale bash è che il nostro Windows sia una versione a 64-bit Anniversary Update build 14393 o superiore. Per verificare la versione del sistema in uso è sufficiente e l’architettura  della CPU della nostra macchina è sufficiente accedere a Impostazioni->Sistema-> Informazioni su.

Inoltre è necessario impostare manualmente il sistema operativo in Modalità sviluppatore (in inglese, Developer Mode). Per farlo è necessario seguire la sequenza Impostazioni -> Aggiornamento e sicurezza -> Per sviluppatori e selezionare l’opzione Modalità sviluppatore. A questo punto non rimane altro che installare la bash accedendo alla funzionalità Attiva o disattiva funzionalità di Windows e selezionando, così come mostrato in figura, la voce sottosistema Windows per Linux.

Per lanciare e utilizzare l’ambiente Linux sarà ora sufficiente aprire una console CMD e digitare il comando bash.

 

Carlo A. Mazzone

Supportaci condividendo sui social il nostro articolo!

Cron: il signore del tempo

In un sistema Linux, capita molto spesso di dover eseguire un certo file, un particolare comando oppure una serie di operazioni in uno specifico momento della giornata. Un caso classico è rappresentato da operazioni di backup dei dati da effettuarsi preferibilemente in orario notturno.

Per realizzare tali scopi i sistemi Linux mettono a disposizione il demone cron che, opportunamente istruito tramite specifici file di configurazione, è in grado di mandare in esecuzione tutto ciò di cui necessitiamo.

Il nome cron deriva probabilmente dal dio greco del tempo Chronos. In realtà l’origne del nome non è certa ed esso potrebbe anche essere l’acronimo derivante dalle espressioni “Commands Run On Notice” oppure “Commands Run Over Night”. In ogni caso il nostro demone legge uno specifico file noto come crontab (ovvero cron table) ed esegue alle temporizzazioni in esso indicate i comandi corrispondenti.

Un prima verifica dello stato del nostro sistema può essere effettuata usando l’apposito comando, chiamato appunto crontab, come mostrato di seguito:

carlo@foo:~$ crontab -l

dove carlo è (ovviamente) il nome dell’utente collegato al sistema e foo il nome della macchina.

L’opzione –l (ovvero il trattino seguito dalla lettera elle) consente di “listare” il contenuto del file di configurazione associato all’utente che lancia il comando in oggetto. Nel nostro caso, e nella situazione in cui il sistema non è ancora stato istruito ad eseguire comandi, dovremmo vedere in output un messaggio del tipo:

no crontab for carlo

Sebbene sia possibile editare direttamente i file di configurazione per i nostri job (attività da eseguire) è conveniente richiamare il file attraverso il comando crontab accodando l’opzione –e, come mostrato di seguito:

carlo@foo:~$ crontab -e

Tale comando aprirà un editor di testi per la modifica di un file predefinito. La prima volta che si richiama il comando in oggetto sarà possibile indicare l’editor di propria preferenza da una lista minimale all’interno della quale si suggerisce l’uso dell’editor nano. Il file di default visualizzato sarà il seguente:

 

# Edit this file to introduce tasks to be run by cron.

#

# Each task to run has to be defined through a single line

# indicating with different fields when the task will be run

# and what command to run for the task

#

# To define the time you can provide concrete values for

# minute (m), hour (h), day of month (dom), month (mon),

# and day of week (dow) or use ‘*’ in these fields (for ‘any’).#

# Notice that tasks will be started based on the cron’s system

# daemon’s notion of time and timezones.

#

# Output of the crontab jobs (including errors) is sent through

# email to the user the crontab file belongs to (unless redirected).

#

# For example, you can run a backup of all your user accounts

# at 5 a.m every week with:

# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/

#

# For more information see the manual pages of crontab(5) and cron(8)

#

# m h dom mon dow command

 

Ovviamente le linee che inziano con il simbolo di cancelletto non sono eseguite in quanto tale simbolo introduce un commento. L’ultima riga indica quale deve essere il formato da utilizzarsi per inserire i comandi da far eseguire al nostro demone. Come si può osservare nelle prime due posizioni indichiamo il minuto (tra 0 e 59) e l’ora (tra 0 e 59) in cui si vuole far eseguire il comando. Successivamente indichiamo il giorno del mese (tra 1 e 31) e il mese dell’anno (tra 1 e 12). Infine, prima del nome del comando possiamo indicare il giorno della settimana in cui verrà eseguito il comando, usando un numero da 0 a 6, dove 0 indica la domenica, 1 il lunedì e così a seguire con il 6 che indica il sabato.

Se si vuole eseguire un dato comando in un giorno qualsiasi è possibile usare un asterisco. Ad esempio la seguente riga:

00 01 * * * /sbin/miocomando

Eseguirà il comando indicato all’una di notte di tutti i giorni della settimana.

Una volta inserita la sequenza di comandi all’interno del file sarà sufficiente salvare il file con CTRL+O e una volta usciti dall’editor (CTRL+X) sarà tuttavia necessario riavviare il demone cron per fargli leggere la nuova configurazione. A tal fine usaremo il comando:

sudo /etc/init.d/cron restart

In alcuni casi, soprattutto quando si è in fase di testing della configurazione può essere utile porsi in ascolto sul log di sistema a caccia di eventuali errori che potrebbero verificarsi. A tal fine useremo il comando:

tail -f /var/log/syslog

A volte è sarà necessario schedulare delle attività che richiedono i permessi di root. In questo caso dovremo lanciare l’editing del file crontab con il prefisso sudo (superuser do) come mostrato di seguito:

carlo@foo:~$ sudo crontab -e

Una volta effettuate le modifiche del caso si procederà con il normale salvataggio prima dell’uscita dall’editor. Volendo visualizzare quindi il file di configurazione specifico per il superutente sarà sufficietne richiamare il comando crontab con l’opzione –l facendo però precedere tale comando dal sudo, come mostrato di seguito:

carlo@foo:~$ sudo crontab -l

Come è intuibile, le opzioni di configurazione sono molteplici. Ad esempio è possibile specificare orari multipli indicandoli separati da una virgola. Nello specifico la riga:

0,15,30,45 * * * * /sbin/miocomando

Schedula il comando per l’esecuzione ogni quarto di ora di ogni ora di ogni giorno.

Infine è possibile utilizzare il simbolo del trattino per indicare specifici intervalli di tempo. Ad esempio:

00 08 * * 1-5 /sbin/miocomando

Schedula il nostro comando per essere eseguito alle otto di mattina di tutti i giorni dal lunedì al venerdì.

 

Carlo A. Mazzone

Supportaci condividendo sui social il nostro articolo!

Abilitazione pagine web su Apache per singoli utenti con userdir

Può essere interessante in ambito laboratoriale o di sviluppo all’interno di un dato gruppo di lavoro abilitare su di una macchina Linux con web server Apache la possibilità per i singoli account utente di utilizzare una specifica cartella per i propri file html e php.
Per farlo è necessario innanzitutto abilitare il modulo userdir con lo specifico comando:

sudo a2enmod userdir

Analizzando il file di configurazione

/etc/apache2/mods-enabled/userdir.conf

si noterà come la cartella nella quale ci si aspetterà di organizzare i file è public_html.

II singolo utente creerà dunque i suoi file nella cartella /home/nomeutente/public_html/
Ovviamente dovrà innanzitutto creare tale cartella, trovandosi nella propria home, con il comando:

mkdir public_html

Per accedere via web con il proprio browser a tali file si userà l’URL:

http://127.0.0.1/~nomeutente/

sostituendo l’indirizzo localhost 127.0.0.1 con l’IP o il nome della macchina in questione.

Gestione PHP
Per abilitare all’esecuzione di script PHP è necessario editare il file:

/etc/apache2/mods-available/php5.conf

In esso bisogna commentare le righe seguenti:
#
#
# php_admin_value engine Off
#
#

Ovviamente bisognerà riavviare apache:

sudo service apache2 restart

Happy coding.

Carlo A. Mazzone

Supportaci condividendo sui social il nostro articolo!

Batch backup: un piccolo script per grandi backup

E’ esigenza diffusa realizzare copie di sicurezza di file personali e/o aziendali su una macchina diversa da quella in cui risiedono i file stessi. In questo micro post vi riporto un semplice script da utilizzarsi su macchine windows verso uno sharing di rete che può essere ospitato tanto su di un server Windows tanto su di una macchina Linux con server Samba.

Si tratta di un file batch molto semplice ma efficace ed efficiente.

Per prima cosa si definiscono un paio di variabili di ambiente che facilitano l’eventuale modifica del file. La variabile LOGFILE contiene il percorso ed il nome di un file di LOG in cui memorizzare le attività svolte dallo script. Una seconda variabile di nome REMOTEDISK indica la lettera di unità di volume dello sharing per la destinazione del backup.

Al lancio lo script accoda nel file di log data ed ora dell’inizio delle operazioni e verifica l’esistenza della destinazione. In caso negativo termina saltando all’etichetta :notarget. Le istruzioni ECHO sembrano ripetitive ma hanno uno scopo. La prima è per la visualizzazione a schermo durante l’esecuzione dello script mentre la seconda serve per accodare, tramite l’operatore di redirezione >>, il testo descrittivo nel file di log.

Se tutto procede come ci si attende le istruzioni xcopy, grazie all’opzione /D,copiano sulla destinazione i soli file modificati. Ciò consente una notevole efficienza dello script. L’opzione /E serve per copiare anche le cartelle vuote in modo da riportare sul disco di backup la reale struttura di origine. L’opzione /Y non chiede conferma per la sovrascrittura dei file.

Da notare l’uso dei doppi apici nel comando xcopy. Nell’esempio non sarebbero strettamente necessari ma risulterebbero indispensabili nel caso di percorsi con spazi presenti al loro interno.

Lo script può essere facilmente inserito nelle attività automatiche di Windows per essere lanciato, nel caso di server aziendali, preferibilmente di notte.

Carlo A. Mazzone

 

@ECHO OFF

CLS
ECHO ************************
ECHO *** BACKUP UTILITY ***
ECHO *** VER 1.1.3 ***
ECHO *** Carlo A. Mazzone ***
ECHO ************************

SET LOGFILE=c:\BackupLogs.txt
SET REMOTEDISK=X:

ECHO *********************** >> %LOGFILE%

DATE /T >> %LOGFILE%
TIME /T >> %LOGFILE%

ECHO Inizio operazioni …
ECHO Inizio operazioni >> %LOGFILE%

REM Test esistenza directory destinazione
IF not EXIST %REMOTEDISK% GOTO notarget

ECHO Copia CARTELLA_1 in corso …
ECHO COPIA CARTELLA_1 >> %LOGFILE%
xcopy “C:\CARTELLA_1\*.*” %REMOTEDISK%\DATI_BACKUP\ /E /D /Y >> %LOGFILE%

ECHO Copia CARTELLA_2 in corso …
ECHO COPIA CARTELLA_2 >> %LOGFILE%
xcopy “C:\CARTELLA_2\*.*” %REMOTEDISK%\DATI_BACKUP\ /E /D /Y >> %LOGFILE%

GOTO fine

:notarget
ECHO Errore – target NON disponibile >> %LOGFILE%
GOTO fine

:fine
DATE /T >> %LOGFILE%
TIME /T >> %LOGFILE%

ECHO Fine operazioni >> %LOGFILE%

ECHO *********************** >> %LOGFILE%

Supportaci condividendo sui social il nostro articolo!

DHCP su Ubuntu: il bello di essere dinamici

La presente brevissima guida descrive in estrema sintesi l’installazione e configurazione di un server DHCP su di una macchina Linux Ubuntu.  Come dovrebbe essere noto il DHCP, ovvero Dynamic Host Configuration Protocol, è un protocollo di rete utilizzato per configurare in maniera dinamica, potremmo dire “al volo”,   le schede di rete al fine di minimizzare gli sforzi necessari per manutenere configurazioni di tipo statico. In soldoni, invece di definire manualmente l’indirizzo IP, la netmask, il gateway di default, DNS, ecc. ecc. necessari per consentire alla specifica macchina di “navigare”    in rete, demandiamo il tutto al server DHCP. E’ intuitivo riflettere sull’utilità di tale approccio soprattutto quando i dispositivi in questione sono di tipo mobile.

Partiamo come di consueto con l’installazione sul server, nel mio caso un Ubuntu 12.04.1 LTS, del pacchetto richiesto:

$sudo apt-get install isc-dhcp-server

Per chi avesse già installato in tempi precedenti un server DHCP c’è da considerare la possibilità di andare in confusione. Infatti, il pacchetto che utilizzavamo un po’ di tempo fa, ovvero dhcp3-server  è stato rinominato in isc-dhcp-server.  In realtà anche se dessimo il comando:

$sudo apt-get install dhcp3-server

il risultato dovrebbe essere lo stesso. Ciò è testimoniato dal fatto che in risposta al comando:

$ apt-cache search dhcp3-server

otteniamo:

isc-dhcp-server – ISC DHCP server for automatic IP address assignment
dhcp3-server – ISC DHCP server (transitional package)
isc-dhcp-server-ldap – DHCP server able to use LDAP as backend

In buona sostanza i due pacchetti sono la stessa cosa.

A voler fare i “precisini”, e chi mi conosce spesso mi mette in questa categoria, il prefisso “isc” nel nome del pacchetto fa riferimento all’ Internet Systems Consortium(ISC), un’organizzazione che sviluppa e manutiene  una varietà di software tra cui  BIND, INN ed appunto una implementazione del DHCP. Per comprendere l’importanza di tale organizzazione pensate che il suo sito web, www.isc.org, ha un page rank Google di 7 che è di tutto rispetto.

Nel caso in cui sul server fossero presenti più schede di rete è possibile “bindare”, cioè legare, ad una specifica eth del server il demone in questione. Tutto ciò è possibile grazie al file:

/etc/default/isc-dhcp-server

Il file di configurazione principale è /etc/dhcp/dhcpd.conf

Al solito, prima di metterci le mani sopra e modificarlo, è saggio farsi una copia di backup dello stesso:

sudo cp /etc/dhcp/dhcpd.conf /etc/dhcp/dhcpd.conf_BAK

Dunque per la modifica si può procedere con:

sudo nano /etc/dhcp/dhcpd.conf

Di seguito una configurazione minimale ma funzionante del suddetto file:

# (configurazione minimale per lan interna )

ddns-update-style none;

option domain-name “example.org”;
option domain-name-servers ns1.example.org, ns2.example.org;

default-lease-time 600;
max-lease-time 7200;

option subnet-mask 255.255.255.0;
option broadcast-address 192.168.0.255;
option routers 192.168.0.1;

subnet 192.168.0.0 netmask 255.255.255.0 {
range 192.168.0.130 192.168.0.254;
}

Per riavviare:

sudo service isc-dhcp-server restart

Nota finale:  per verificare i lease è possibile usare il comando:

sudo tail /var/lib/dhcp/dhcpd.leases

Hope this helps 😉

Carlo A. Mazzone

Supportaci condividendo sui social il nostro articolo!

Consentire il cambio password su macchine Linux via web: Usermin è questo e tanto altro

La prima volta che feci conoscenza con il pacchetto Usermin fu quando ero in cerca di un sistema per consentire agli utenti, gestiti tramite una macchina Linux, di poter cambiare la propria password senza costringerli all’uso della shell testuale tramite un brutale passwd.

Usermin, una interfaccia web molto simile a Webmin, consente questa e tante altre possibilità.

Infatti Usermin consente ad utenti non amministratori (non root) di macchine Unix like di eseguire operazioni che dovrebbero essere normalmente realizzate tramite il prompt della shell. La similarità con Webmin è dovuta al fatto che gli autori sono gli stessi per entrambi i pacchetti mentre al differenza sostanziale, come avreste dovuto già intuire, è data dal fatto che Webmin è indirizzato agli  utenti che si loggano come root, essendo amministratori del sistema, mentre Usermin è dedicato agli utenti normali.

Tra le varie possibilità messe a disposizione da Usermin al “normal user” loggato via web mi viene da citare l’interfaccia webmail, la possibilità di configurare il proprio  Procmail per la gestione del forwarding e dello spam, la gestione di database  MySQL e PostgreSQL e la modifica del file .htaccess.

Ovviamente l’amministratore può definire un controllo molto fine su quali di queste operazioni risultano disponibili all’utente in questione.

Dopo questo ampio preambolo credo proprio sia il caso di passare all’azione.

La procedura descritta è stata verifica su di una macchina Linux Ubuntu ed il modo migliore  che consiglio in tale contesto  per installare ed aggiornare Usermin è quello di usare APT (Advanced Packaging Tool).

La prima operazione è richiesta è dunque quella di modificare il file  /etc/apt/sources.list aggiungendo la riga seguente:

deb http://download.webmin.com/download/repository sarge contrib

Attenzione che questa riga è la stessa richiesta per Webmin per cui se quest’ultimo lo  si  è già installato non è necessario aggiungerla. Installare preventivamente Webmin è proprio quello che vivamente consiglio in quanto l’amministrazione di tutte le funzionalità di Usermin saranno gestite appunto tramite l’interfaccia web di Webmin in maniera del tutto naturale. L’alternativa consisterebbe nell’editing diretto dei file di  configurazione nella directory /etc/usermin.

Procediamo dunque con l’installazione di Usermin lanciando i seguenti comandi:

apt-get update
apt-get install usermin

Tutte le dipendenza richieste dovrebbero essere risolte in maniera automatica.

Se tutto sarà andato per il verso giusto sarà sufficiente loggarsi con la userid e la password di un qualsiasi utnte Unix all’URL seguente:

https://serverip:20000/

Dove 20000 è il numero di porta utilizzato da Usermin rispetto al numero 10000 utilizzato da Webmin.

A questo punto l’ultima cosa che che mi sento di segnalare è che per poter selezionare ed indicare quali tra i vari moduli di Usermin devono essere visibili  agli utenti è sufficiente accedere alla sezione “Avalilable Modules” accessibile dopo un clic sulla voce “Usermin Configuration” della sezione Webmin nella treeview di amministrazione.

Alla prossima.

Carlo A. Mazzone

Supportaci condividendo sui social il nostro articolo!

Webmin: amministra il tuo server Linux dal browser web

Webmin è un utilissimo strumento di amministrazione per server Linux. Esso consente tramite un semplice accesso via web di configurare ed amministrare svariati servizi: apache, dns, dhcp  solo per citarne alcuni. Webmin consente inoltre  di gestire account e lavorare sul file system del server sul quale è installato. Ma anche questo è un elenco estremamente riduttivo delle sue possibilità. In definitiva in un solo ambiente è possibile avere sotto le proprie dita un intero sistema server.

Il presente scritto vuole essere una veloce guida alla sua installazione.

Dunque partiamo. La prima operazione da portare a termine è la modifica del file  /etc/apt/sources.list

Per farlo usate il vostro editor preferito; il mio, da un po’ di tempo a questa parte,  è “nano”. Quest’ultimo lo sto preferendo al vecchio “vi” essendo ormai disponibile di default in varie distribuzioni Linux. Ed a proposito di distribuzione la procedura qui descritta è stata provata su di una distro Linux Ubuntu server 12.04 64 bit.

Procediamo allora con:

$ sudo nano /etc/apt/sources.list

Il file in questione  è utilizzato dal gestore di pacchetti APT per contenere la lista delle “sorgenti” dalle quali il sistema può attingere i pacchetti stessi.

Andiamo dunque ad aggiungere al file in questione le seguenti due righe di testo:

deb http://download.webmin.com/download/repository sarge contrib
deb http://webmin.mirror.somersettechsolutions.co.uk/repository sarge contrib

Salviamo il file ed usciamo.

A questo punto è necessario  importare la chiave GPG per validare il pacchetto webmin. In caso contrario potreste ricevere durante l’installazione un errore come il seguente:
“Le seguenti firme non sono state verificate perché la chiave pubblica non è disponibile”

Lanciamo dunque i seguenti comandi:

$ wget http://www.webmin.com/jcameron-key.asc
$ sudo apt-key add jcameron-key.asc

Aggiorniamo dunque la source list:

$ sudo apt-get update

e finalmente possiamo procedere all’installazione di webmin:

$ sudo apt-get install webmin

E dunque ci siamo; per accedere al pannello di controllo è sufficiente raggiungere l’URL:

https://serverip:10000/
Supportaci condividendo sui social il nostro articolo!

SubVersion con Apache 2 su Linux Ubuntu 11.10

Di seguito una revisione di un articolo già pubblicato relativo alla versione Ubuntu 7.04.

Hope this helps.

Qualsiasi programmatore che abbia sviluppato in team con altri sviluppatori si sarà reso conto della necessità di condividere pezzi di codice con gli altri elementi del gruppo e delle difficoltà legate a tale condivisione. Fortunatamente esistono software appositamente progettati per consentire a differenti sviluppatori di lavorare sugli stessi progetti controllando le modifiche apportate ed evitando sovrascritture accidentali degli stessi frammenti di codice.

Oltre al classico “SourceSafe” prodotto dalla Microsoft ed agli strumenti messi a disposizione nell’ultima, e molto costosa, suite Microsoft Visual Studio Team Edition, ha preso piede in questi ultimi tempi un sistema gratuito e molto affidabile chiamato SubVersion. Tale software sembra stia soppiantando nei gusti dei sistemi un po’ di tutto il mondo un software analogo di nome CVS (Concurrent Versions System) dal quale SubVersion prende le mosse.

In questo articolo vediamo come installare la parte server di SubVersion su di una distribuzione Linux Ubuntu. Nello specifico il tutto è stato provato con la versione 11.10.

Si presuppone che sul sistema sia installato Apache 2.

Il pacchetto indispensabile per subversion è semplicemetne “subversion”

Per cui procediamo alla sua installazione utilizzando il comando apt-get:

$ sudo apt-get install subversion

Il comando provvederà ad installare i moduli necessari, SubVersion e SVN per Apache.

Il modulo SVN dovrebbe essere automaticamente abilitato dopo l’installazione. Se così non fosse è possibile utilizzare il comando “a2enmod”, uno script che abilita il modulo specificato, ad esempio, nel nostro caso:

$ sudo a2enmod dav_svn

Incidentalmente faccio notare che esiste un comando con funzione opposta, vale a dire per disabilitare un modulo: “a2dismod [nome modulo]”

CREAZIONE DEL REPOSITORY SVN

Installeremo il repository in /svn

Creiamo come prima cosa il gruppo ‘subversion’

$ sudo groupadd subversion

Aggiungiamo l’utente Apache, ovvero www-data, al gruppo subversion appena creato.

$ sudo usermod -G subversion www-data

Da notare come con il comando $ groups www-data sia possibile verificare il successo del comando precedente.

Passiamo ora alla creazione della cartelle fisiche sul file system per i repository:

$ sudo mkdir /home/svn

Spostiamoci nella cartella appena creata e creaiamo una ulteriore nuova cartella per il nostro primo progetto:

$ cd /home/svn

$ sudo mkdir tesseract

A questo punto passo alla creazione dle repository vero e proprio

$ sudo svnadmin create /home/svn/tesseract

Passiamo ora alla corretta impostazion dei permessi:

$ cd /home/svn

$ sudo chown -R www-data:subversion tesseract

Dove, con l’ultimo comando, impostiamo per la cartella ‘tesseract’ ed in maniera ricorsiva per tutte le sottocartelle come prorietrartio l’utente ‘www-data’ e come gruppo ‘subversion’

Ed infine:

$ sudo chmod -R g+rws tesseract

Per abilitare lettura e scrittura (rw) per il gruppo. Da notare il flag ‘s’. Questo, detto di norma setuid e’ necessario in quanto svnadmin deve creare i file durante operazioni tipo  commit.

CONFIGURARE L’ACCESSO A SVN

I repository di SVN possono essere gestiti tramite vari protocolli (file, http, https, svn+ssh, …). Sicuramente, il piu’ semplice è l’accesso via protocollo WebDAV (http://).

Per utilizzare questo protocollo è necessario configurare correttamente Apache. Si presuppone quindi l’installazione del pacchetto libapache2-svn:

$ sudo apt-get install libapache2-svn

Sarebbe possibile apportare le modifiche del caso al file /etc/apache2/mods-enabled/dav_svn.conf, tuttavia ciò non è possibile nel caso di configurazione sulla macchina server di hosts virtuali (vhosts).

E’ questa la tipologia di configurazione che personalemtne prediligo per cui suggerisco la modifica dei file in /etc/apache2/sites-available/*

La cartella “/etc/apache2/sites-available/” contiene un file di configurazione per ogni sito virtuale disponibile sulla macchina. Ne esiste uno predefinito, con nome “default”. E’ possibile modificare direttamente questo file con le opportune proprie “customizzazioni” e, nel caso sia necessario rendere disponibile un nuovo sito virtuale, è possibile duplicare il file in questione (utilizzando un nome a piacimento) e modificarlo seconda necessità.

La cartella in questione elenca, come dice il nome stesso, i siti disponibili sulla macchina. Essere disponibile non è sufficiente: bisogna anche che il sito sia abilitato. A tale scopo esiste una utility “a2ensite” che abilita il sito specificato. Ciò che tale utility realizza è la creazione di un link simbolico nella cartella /etc/apache2/sites-enabled/ che punta al file di configurazione del sito specificato. Un utility complementare, “a2dissite”, consente di disabilitare momentaneamente uno specifico sito senza costringere a cancellare o rinominare il file di configurazione.

La lettura dei file “enabled”, cioè abilitati, è resa possibile dalla direttiva:

“Include /etc/apache2/sites-enabled/”

presente nel file di configurazione principale di Apache.

Un tipico file di configurazione di un host sarà qualcosa del tipo:

<VirtualHost 192.168.1.1:80>

DocumentRoot /home/test/public_html

ServerName nomesito.tesseract.it

<Location /svntest>

DAV svn

SVNListParentPath on

SVNPath /home/test/repositories/test1

AuthType Basic

AuthName “Tesseract SVN test repository”

AuthUserFile /etc/apache2/users

AuthGroupFile /etc/apache2/groups

Require group developers

</Location>

</VirtualHost>

Da notare che dovranno essere presenti nel file di configurazione generale (apache2.conf) le seguenti righe:

NameVirtualHost 192.168.1.1:80

Dove 192.168.1.1 è l’IP della vostra macchina server

Include /etc/apache2/sites-enabled/

Per includere i file di configurazione degli host virtuali.

Per aggiornare il server al nuovo stato dare il comando:

sudo /etc/init.d/apache2 reload

APACHE E IL CONTROLLO DEGLI UTENTI

Per memorizzare le informazioni relative agli utenti e relative password per l’accesso ai contenuti è necessario creare un apposito file.

Tale file, per ovvie ragioni di sicurezza, deve essere registrato in una posizione tale da non essere accessibile da web. Esso, inoltre, non può essere editato direttamente a mano; le password, infatti, sono registrate in forma cifrata.

Il programma utilizzato per tale gestione è “htpasswd”:

Per iniziare è necessario creare il file in questione indicando un primo nuovo utente da inserire nel file stesso:

htpasswd -c /etc/apache2/users carlo

Il comando, con l’opzione -c, crea il file “users” nella directory /etc/apache2/ chiedendo la password da associare all’utente (nel nostro caso, l’utente “carlo”).

Il contenuto del file “users” dovrebbe essere ora simile al seguente:

——————————————-

carlo: xx1LtcDbOY4/K

——————————————-

dove si individua il primo campo contenente il nome utente ed il secondo campo, separato dal simbolo “:” contenente la password in forma cifrata.

Per inserire nuovi utenti all’interno del file riusiamo il comando htpasswd, omettendo ovviamente il flag -c in quanto il file è stato già creato; ad esempio, il comando:

——————————————-

htpasswd /etc/apache2/users giuseppe

——————————————-

aggiunge al file /etc/apache2/users l’utente “giuseppe”

Nella sezione “<Location></Location>” si utilizzano una serie di direttive per configurare i contenuti del repository ed i relativi accessi.

Vediamo in dettaglio le principali tra tali direttive:

SVNPath valorizzato nel nostr caso con il percorso “/home/test/repositories/test1” indica, appunto, il percorso fisico del repository. Tale percorso viene raggiunto tramite la redirezione impostata con “<Location /svntest>”.

In concreto l’URL http://nomeMacchina/svntest redirigerà il browser nel repository specificato dal valore impostato in “SVNPath”.

AuthName indica un nome per la zona, ovvero l’insieme di file e cartelle, per le quali si vuole controllare l’accesso. Esso rappresenta quello che in gergo tecnico viene definito “realm”. Un realm rappresenta, appunto, una zona del file system, generalmente una directory con eventuali sottodirectory che si intende proteggere. Una volta avvenuta l’autenticazione relativamente ad un certo realm questa viene conservata per la sessione corrente e sarà valida anche in una zona differente purchè avente lo stesso nome di realm.

AuthType indica il protocollo da utilizzarsi per l’autenticazione. Basic è quello predefinito.

AuthUserFile indica al server il nome e la posizione del file da contenente le credenziali di accesso.

Nel caso si volessero usare dei gruppi, anzichè gestire il singolo utente, è possibile utilizzare la direttiva AuthGroupFile

require indica gli utenti che possono avere accesso al realm specificato: Nel caso si voglia abilitare tutti gli utenti indicati nel file delle password è sufficiente valorizzare la direttiva require con il valore valid-user.

In caso contrario, nel caso si volesse autorizzare un sottoinsieme di utenti sarà sufficiente indicare i loro nomi dopo la direttiva stessa. Ad esempio:

require user carlo giuseppe

abilita all’accesso i soli utenti “carlo” e “giuseppe”

Nel caso di situazioni più complesse è possibile ricorrere alla gestione dei gruppi utilizzardo la direttiva AuthGroupFile e specificando il file contenente le informazioni sui gruppi stessi. Un file di tale tipo è organizzato in una sequenza di righe contenenti i nomi dei gruppi e, separati dal sibolo “:”, l’elenco degli utenti appartenenti allo specifico gruppo:

amministratori:carlo giuseppe

segreteria:anna isabella antonella

Per l’autenticazione si può poi procedere, ad esempio, come segue:

require group amministratori segreteria

require user carlotta

Tali direttive abilitano, dopo l’inserimento delle giuste credenziali, gli utenti dei gruppi “amministratori” e “segreteria” e l’utente “carlotta”, all’accesso alle risorse del realm.

Il client di accesso a SubVersion

Come client è possibile usare TortoiseSVN (http://tortoisesvn.net). Si tratta di un software gratuito per Windows che si integra perfettamente in “gestione risorse”.

Carlo Mazzone

www.tesseract.it

Supportaci condividendo sui social il nostro articolo!