Il progetto, fino ad oggi tenuto in gran segreto nei suoi dettagli, è in realtà in via di sviluppo da più di un anno e solo pochi (pochissimi) “intimi” sviluppatori ne conoscevano i dettagli.

Ma vediamo le grandissime novità che saranno – in futuro, visto che è lecito attendersi ancora almeno un anno di intenso sviluppo prima di essere rilasciato nella sua prima versione stabile – sotto i nostri occhi.

Cominciamo subito: aMSN2 è basato su tre livelli (protocollo, core e GUI).

1. Il protocollo adottato è pymsn;
2. la GUI è “slegata dal programma”, cosicchè diverse GUI possono essere utilizzate;
3. il core è programmato in python e non più in tcl/tk.

Cerchiamo di dare qualche informazione in più:

1. il protocollo:

aMSN2 userà la libreria pymsn per tutte le funzioni legate al protocollo. Pymsn è infatti la prima libreria che ha implementato MSNP15 ed ha al suo interno le necessarie funzioni per implementare il protocollo MSNP16. KaKaRoTo (o Youness Alaoui che dir si voglia) assisterà il team di Pymsn per sviluppare le funzioni necessarie ad aMSN2.

2. la GUI:

Disattendendo tutte le attese, aMSN2 spiazza tutti scegliendo – forse come front end predefinito – una GUI basata sulle librerie EFL (Enlightenment), di cui qui potrete trovare un primo video dimostrativo!

Ma, come anticipato, la novità continua: aMSN2 disporrà di una GUI per MAC, un front end ncurses (per gli appassionati del terminale), una GUI gtk, una QT e un’ultima XUL. Ce n’è per tutti i gusti, no??

C’è di più: la GUI in GTK sarà direttamente mantenuta dal team di sviluppo di emesene, che in quest’anno ha mostrato di saper lavorare egregiamente! Addirittura 4 persone di questo team hanno deciso di contribuire direttamente al progetto aMSN2!

Che sia in vista una “reunion” in grande stile?? No, non credo, certo è che l’open source anche in questo caso dimostra la sua forza: l’esperienza di uno si tramuta nell’esperienza di tutta la comunità!!

3. il core:

Come detto, aMSN2 sarà sviluppato in python. Tale scelta è stata mantenuta segreta fino ad oggi ed è stata oggetto di un lungo dibattito interno tra i maggiori sviluppatori del progetto: Youness Alaoui, Philippe Valembois, Harry Vennik e Tom Hennigan.

KaKaRoTo spiega la scelta affermando che è stata fatta per evitare ogni tipo di flame, come quelli che scoppiano ogni volta che si sceglie un linguaggio al posto di un altro. Ora – dice – la scelta è stata fatta, quindi è inutile discuterne ancora.

Riguardo a questo argomento tra l’atro KaRaKoTo si era già espresso in mailing-list il 17 gennaio 2008 (in inglese):

I had a working/semi-usable aMSN2 ready since last july, but I didn’t have time to clean it/polish it/finish it, in order to release it…
The design is done and will not change as we think that this is what aMSN2′s future should be. We made very thorough decisions involving a LOT of research and proof of concepts meant to be thrown away to test various theories, we reviewed a lot of solutions and considered all the things that aMSN2 needs in terms of usability, performance, development time, team involvement, team motivation, knowledge transfer, GUI of course, language, libraries to use, etc…
We made decisions that will most benefit aMSN2 in every aspect considered, BUT of course, not everyone can be happy… for example, if we decided to use GTK, all QT lovers will rant, if we decided to choose QT, all GTK lovers will rant, if we decided to use something all, maybe the whole world will
rant. The same can be applied to the language.
For this specific reason, we chose not to disclose anything, because if we do, we will generate a huge flame war which will never end and aMSN2 will never see the light. We want to avoid flame wars, trolling, etc.. and since there will always be someone unhappy about our choices, we will have to make a decision for everyone and impose it, force it to the community as ‘the decision’, and not ‘the proposal’. And as experience serves, when we decide something and implement it, and people try it, it’s accepted, if we ask about it, none agrees and nothing gets done (take for example all the lengthy discussions we had on the ML and what about the on-line spaces thing, etc.. once implemented, everyone’s happy, and none is when it’s being discussed).
For that reason, we decided to keep it all a secret, and not talk about it. And this email will only generate flaming, I already see 10 people getting all excited and starting to type about how cool it would be if we chose python, and another 10 people writing how python would be a bad choice, and
let’s not talk about all the dbus-haters and/or the people who do not want to see telepathy added to the project.. another few people will be happy to see telepathy added and will start a flamewar about whether aMSN should be multiprotocol or single protocol stating that telepathy will allow us to be multiprotocol easily, etc … It will generate a lot of useless, time wasting talk about something that was already designed, decided, and written and will not change anytime soon.

Certo, lo si potrebbe accusare un po’ di decisionismo, tuttavia è bene considerare il tutto sotto due aspetti:

a. dal punto di vista pratico, un mantainer di un progetto DEVE fare delle scelte strategiche, perchè è grazie ad esse che il progetto può avanzare. In bene o in male, ma in ogni caso la responsabilità è sua.

b. dal punto di vista teorico, la filosofia open-source non impedisce di prendere autonomamente delle decisioni, ma di far in modo di lasciare agli altri la possibilità di accettarla o di rifiutarla, prevalentemente rilasciando i codici sorgenti del proprio lavoro. Questo vuol dire che se qualcuno non fosse d’accordo con la scelta di usare python, potrebbe benissimo creare un nuovo progetto scritto in un qualsiasi altro linguaggio.

Le novità quindi sono moltissime, il progetto davvero all’avanguardia ed il lavoro ancora molto.

Pur non essendo un appassionato dell’istant messaging (ho un account msn che non uso praticamente mai), devo dire che la curiosità è tale da… poter decidere tra qualche mese di riaccedere al mio account dal mio nuovo aMSN2 fiammante!

enjoy,

giopas

ps: il repository di sviluppo lo trovate qui

Tuttavia, prima di iscrivermi vorrei conoscere le attività, le persone e finanche il tempo richiesto. Ecco perciò che ho spedito al Lug la seguente lettera (in inglese).

Ometto qui nel testo alcuni nomi per motivi di privacy.

Dear LiLUX,

I’m a Linux user living in Luxembourg and I’m interested to share my interests with some other people here around.

Unfortunately I missed last Linux Day, but I’m curious to meet you all.

As far as I can see, Linux – and opensource in general – is still not so common in Luxembourg financial sector and I wonder to know if there is any project or event organized to spread opensource philosophy (or better, working approach) to it.

I try to explain my feelings telling you a short experience.

Last month, I’ve been at the Internet Security Day 2.0 organized by the “Ministère de l’économie et du Commerce Extérieur (luxembourgeois)” in order to make enterprises/companies awaken of security concerns using Internet. However, I noticed that during the entire event nobody mentioned opensource as a possible jointly held solution to improve (at least, internet) security.

For this reason (maybe someone of you was there and remembers it) I explicitly asked to the speaker (Mr. xxxxxx of CASES – www.cases.lu) what was the official CASES’ position toward the adoption of opensource solutions as instrument of improving IT security.

The embarrassing answer I obtained was that “CASES is neutral”, and that he “could not see much people in [that] conference room able to debug an opensource software like OpenOffice.org”!

The meaning was clear: “Hey boy, don’t you see that here around you are surrounded by a lot of IT consultants wandering to advertise their closed-source product for improving user security?? The opensource argument is TABOO here!”.

I already knew the answer, but I thought to be important to make this hypocrisy open and clear.

Actually, I’m not a Linux hysterical, however I’m astonished to see how a growing and reach IT financial community like the Luxembourg one is far from considering opensource a substantial solution (or alternative) for common or professional users.

So little IT companies offer Linux support in the financial sector in Luxembourg…

I hope to be wrong, of course, but I don’t think so.

For these reasons I would like to contribute in a more practical way (as long as I can, because I’m not a coder/developer/geek and unfortunately I don’t have a lot of time to offer) to the opensource case. I hope therefore you could give me more information about your activities and events so that I can see if and how I could contribute to LiLUX program.

Best regards,

giopas

ps: I hope that community/working language is English or French

Come già fatto da qualcuno e qualche mese fa da qualcun altro riporto qui di seguito le frasi del celeberrimo cantautore italiano, con la precisa intenzione di contribuire in minima parte ad attenuare il clima ostile creatosi in quest’ultimo periodo verso questa popolazione, alla quale mi sento legato fin dall’infanzia: quando ho avuto come compagno di classe il mio amico rom Baretta.

“(…) è il caso del popolo Rom, quello che noi volgarmente chiamiamo “Zingari” prendendo a prestito il termine da Erodoto, che li chiamava “Zinganoi” – diceva che era un popolo che veniva dal sud-est asiatico, dall’India, che parlavano una strana lingua – che poi si è scoperto essere il Sanscrito – e che facevano un mestiere (se mestiere lo si può considerare): quello del mago e dell’indovino.
E’ quindi un popolo che gira il mondo da più di 2000 anni, afflitto o affetto – io non so come meglio dire, ma forse semplicemente affetto – da quella che gli psicologi chiamano “dromomania”, cioè la mania dello spostamento continuo, del viaggiare, del non fermarsi mai in un posto. E’ un popolo, secondo me, che meriterebbe – per il fatto, appunto, che gira il mondo da più di 2000 anni senza armi – meriterebbe il premio per la pace in quanto popolo.
Purtroppo i nostri storici – e non soltanto i nostri – preferiscono considerare i popoli non soltanto in quanto tali ma in quanto organizzati in nazioni, se non addirittura in stati, e si sa che i Rom – non possedendo territori – non possono considerarsi né una nazione né uno stato. Mi si dirà che gli zingari rubano; è vero, hanno rubato anche in casa mia. Si accontentano, però, dell’oro e delle palanche; l’argento non lo toccano perchè secondo loro porta male, lascia il nero – quindi vi accorgete subito se siete stati derubati da degli zingari. D’altra parte si difendono come possono; si sa bene che l’industria ha fatto chiudere diversi mercati artigianali. Buona parte dei Rom erano e sono ancora artigiani, lavoratori di metalli (in special modo del rame), addestratori di cavalli e giostrai – tutti mestieri che, purtroppo, sono caduti in disuso. Gli zingari rubano, è vero, però io non ho mai sentito dire – non l’ho mai visto scritto da nessuna parte – che gli zingari abbiano rubato tramite banca. Questo è un dato di fatto.”

Che dire? Sicuramente queste parole non risolvono il complesso problema della convivenza e dell’integrazione (nella salvaguardia delle reciproche tradizioni/necessità) tra i cittadini italiani ed i rom. Tuttavia spero che citare un “Maestro” serva a qualcuno per farlo fermare a riflettere sull’intera problematica cercando di astrarsi dai fatti di cronaca che ossessivamente (e che ancora e solo per qualche settimana ancora, com’è solito nella stampa) ci vengono sottoposti.

enjoy,
giopas

ATTENZIONE, nella maggiorparte dei casi questa guida non è più di attualità (per installare la webcam). Tuttavia, può essere utile per imparare a gestire le periferiche su Linux.

Linux 2.6.26 and newer includes the Linux UVC driver natively. You will not need to download the driver sources manually unless you want to test a newer version or help with development. (fonte)

—— ORIGINAL POST ———

Visto che pian pianino sto diffondendo l’uso di Linux agli amici un po’ più “scafati”, mi trovo talvolta a dover fare il mentore (io!!!) su alcune comuni problematiche.

Ecco perchè, come potrete leggere qui sotto, per spiegare un’operazione di per sè semplice, come fa andare la webcam su Ubuntu 8.04 (anche se io uso fieramente Debian ), ne ho approfittato per dargli qualche semplice nozione di base.

Ovviamente pubblico quanto scritto per chi altro potesse averne bisogno!

Ovviamente il linguaggio potrebbe non essere molto preciso, sia per ignoranza mia che per rendere la già eccessivamente lunga email un po’ più semplice da leggere… dico solo che sono quattro giorni che l’ho scritta, ed ancora non ho avuto un feedback! Poverino, forse l’ho spaventato! LOL

Ciao,

come promesso ti invio qualche istruzione su come far andare la webcam su linux. Invece di darti solo dei comandi, ti spiego anche il ragionamento.

Se non sei interessato, salta direttamente al punto 2!

1a. capire che chipset monta la webcam.

Infatti uno stesso chipset può essere usato da diverse marche, un po’ come uno stesso motore su macchine diverse.

Per sapere quale chipset ha la tua webcam e quindi quale driver installare, aprire il terminale e, una volta attaccata la webcam all’usb digitare:

$ lsusb

Il risultato che avrai è qualcosa del genere:

Bus 003 Device 005: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Bus 003 Device 004: ID 04b4:6830 Cypress Semiconductor Corp. CY7C68300A EZ-USB AT2 USB 2.0 to ATA/ATAPI
Bus 003 Device 002: ID 046d:08c5 Logitech, Inc. QuickCam Pro 5000
Bus 001 Device 002: ID 046d:c03e Logitech, Inc. Premium Optical Wheel Mouse

Già qui dovresti vedere che il sistema ha riconosciuto la webcam.

In genere però, se vuoi sapere se il sistema “vede” il dispositivo che hai collegato, il comando è il seguente:

$ sudo tail -f /var/log/messages

Il risultato nel mio caso è che ho collegato qualcosa alla porta usb (3-1) e che, visto che il sistema ha già installato il driver – che ti insegnerò ad installare – (UVC 1.00 device) capisce che quello che ho inserito (046d:08c5) è una webcam che funziona con il suddetto driver.

May 14 19:31:09 giolaptop kernel: [40818.340648] usb 3-1: new high speed USB device using ehci_hcd and address 7
May 14 19:31:10 giolaptop kernel: [40818.634916] usb 3-1: configuration #1 chosen from 1 choice
May 14 19:31:10 giolaptop kernel: [40818.634916] uvcvideo: Found UVC 1.00 device (046d:08c5)
May 14 19:31:10 giolaptop kernel: [40818.812262] input: UVC Camera (046d:08c5) as /class/input/input8
May 14 19:31:10 giolaptop kernel: [40818.824164] usb 3-1: New USB device found, idVendor=046d, idProduct=08c5
May 14 19:31:10 giolaptop kernel: [40818.824183] usb 3-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0

Un altro comando del genere è il seguente (è bene che tu li conosca per sbrogliartela in qualsiasi situazione!):

$ dmesg | tail

Il risultato in questo caso è più stringato, ma ugualmente utile:

[40818.634916] uvcvideo: Found UVC 1.00 device (046d:08c5)
[40818.812262] input: UVC Camera (046d:08c5) as /class/input/input8
[40818.824164] usb 3-1: New USB device found, idVendor=046d, idProduct=08c5
[40818.824183] usb 3-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0

Facile no? Tre modi diversi per avere la stessa informazione!

Ma c’è un ultimo comando che può servirti per conoscere TUTTI i componenti che hai collegato o che costituiscono il pc:

lspci (o anche lspci -n)

Il risultato può essere ad esempio il seguente:

00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 74)
01:00.0 VGA compatible controller: S3 Inc. VT8375 [ProSavage8 KM266/KL266]
02:00.0 Ethernet controller: Atheros Communications Inc. AR5212/AR5213 Multiprotocol MAC/baseband processor (rev 01)

Già hai trovato un sacco di info sul pc, ed in caso di problemi sai da dove partire su google!

Ah, dimenticavo, tutte queste informazioni le puoi anche trovare con interfaccia grafica: Sistema -> Preferenze -> Gestore Periferiche (su GNOME)…

1b. Utilizzare le informazioni trovate:

Dalla nostra ricerchina, ci bastava il primo metodo per la verità, hai scoperto quello che cercavi: l’identificativo del chipset.

Nel mio caso il codice del venditore e il codice del prodotto sono i seguenti “idVendor=046d” e “idProduct=08c5″ o, come hai visto anche “046d:08c5″.

Ora, la cosa più semplice è andare su google e digitare qualcosa come “046d:08c5 linux” e vedere i risultati!

Ma noi faremo ancora più semplice.

2. Cercare se il driver è supportato

Noi sappiamo che la tua webcam è una Logitech, ebbene, la maggioranza dei chipset che monta sono supportati dal driver UVC.

Quindi verificheremo che la tua webcam sia effettivamente supportata guardando questa lista: http://linux-uvc.berlios.de/

Come potrai vedere, la prima colonna contiene quel codice che abbiamo trovato al punto 1. Bello no? Quello che farai sarà quindi di cercare nella tabella il modello di webcam che hai, facendo attenzione a che il codice a sinistra sia lo stesso tuo e vedrai se la webcam è supportata o no dal driver UVC. Se per caso non lo fosse, non disperare: cerca su google come ti ho suggerito al punto 1b.

3. Installare il driver

Ora che sappiamo che la webcam è supportata (o parzialmente, ma non disperiamo), ci accorgeremo di una bella cosa: che ubuntu ha già integrato il driver uvc nel kernel!!

Quello che dovremo fare allora sarà semplicemente digitare sul terminale per caricare il modulo (o driver) nel kernel:

$ sudo modprobe uvcvideo

Riavviare ed installare (se non ottieni errori) luvcview per testare:

$ sudo aptitude install luvcview

3. Se per caso avessi trovato un errore nel caricare il modulo, proviamo ad aggiornarlo con uno più recente.

Installiamo allora i componenti di sviluppo per compilarci il modulo fresco fresco (ciò che potrebbe anche essere utile per avere il video su skype, anche se non mi sono mai sbattuto per farlo funzionare). Da terminale:

$ sudo aptitude install linux-headers-`uname-r` subversion devscripts make build-essential

Dopodichè mi scarico i sorgenti del modulo e li compilo (creando prima una cartella):

$ mkdir SVN/ && cd SVV/
$ svn co svn://svn.berlios.de/linux-uvc/linux-uvc/trunk uvc/
$ cd uvc
$ make
$ sudo make install
$ sudo modprobe uvcvideo

In caso di errore, dare i due seguenti comandi:

$ sudo depmod -ae `uname -r`
$ sudo /sbin/modprobe uvcvideo

Fatto! Ora, se lanciamo luvcview, dopo aver riavviato (anche se non è strettamente necessario), dovremmo vedere il nostro bel facccione!!

4. Piccola messa a punto.

Se la tua webcam ha il microfono integrato ma non lo usi, potresti voler disattivarlo del tutto, così da non complicarti la vita con due (o più) microfoni tra i piedi!

Quello che devi fare è semplicemente di aprire il file di testo /etc/modprobe.d/blacklist come segue:

$ sudo nano /etc/modprobe.d/blacklist

e aggiungere in fondo la seguente riga:

blacklist snd_usb_audio

Per salvare, cliccare su “ctrl”+”o” (di Otranto), premere “invio” e poi “ctrl”+”x”

Fine!! E’ molto più lungo a spiegare che a mettere in pratica (però volevo che ne approfittassi per imparare qualcosa di utile… solo sul pinguino, visto che su windows se qualcosa non va… ti attacchi)!

Se hai problemi fammi sapere dandomi le informazioni come al punto 1 e vediamo di risolvere!

Buona serata.

1. da circa un anno e mezzo – credo – ho come webcam una Logitech 5000pro
2. e che sono piuttosto allergico ai protocolli di messaggistica istantanea closed (msn e skype)

ho pensato di utilizzare la webcam per catturare immagini o video direttamente dal mio pc portatile, così da non aver più problemi di batterie o schede di memoria quando ho già tutto il necessario!

Non avendo però bisogno o voglia:

1. di usare il dispositivo per videosorveglianza (per la quale motion sarebbe stato lo strumento ideale)

2 di usare comandi da console come ffmpeg (troppi parametri diversi che una volta scoperti, avrei dimenticato da qualche parte recondita del pc);

mi sono dato alla ricerca di un tool grafico che potesse farmi registrare il flusso video in ogni momento con un paio di click!

Prima di spiegare quale tool ho utilizzato, preciso che la mia webcam è la seguente:

giopas@giolaptop:~$ lsusb |grep Logitech
Bus 001 Device 002: ID 046d:c03e Logitech, Inc. Premium Optical Wheel Mouse

Per farla funzionare, ho semplicemente usato il driver uvc che si può scaricare dai repository debian “linux-uvc” e compilato con module assistant:

# modprobe v4l1_compat videodev v4l2_common
# aptitude install linux-uvc-source linux-uvc-tools libpt-plugins-v4l2 v4l2ucp subversion libsdl1.2-dev
# m-a a-i linux-uvc

Altro modo è quello di usare la versione di sviluppo (io uso in effetti questa):

~ $ svn co svn://svn.berlios.de/linux-uvc/linux-uvc/trunk uvc/
~/trunk $ make
~/trunk # make install && modprobe uvcvideo

Dopo questo piccolo excursus (giusto per chi ne avesse avuto bisogno), ecco il tool che ho trovato: guvcview.

Il progetto è giovane ma molto attivo (basta vedere le frequenti release nella homepage) e fornisce una finestra di configurazione grafica molto semplice per catturare immagini o video con le webcam supportate dal driver uvc.

Ecco arrivati al punto fondamentale. L’installazione, che su Debian potrebbe dare qualche noioso problema di risoluzione delle dipendenze:

# aptitude install libportaudiocpp0 libportaudio-ocaml-dev autoconf automake
libglib2.0-dev libportaudio-ocaml-dev libsdl1.2-all libsdl1.2-dev libsdl1.2debian-all libpng-dev libgdk-pixbuf2
~/SVN$ svn checkout svn://svn.berlios.de/guvcview/trunk guvcview
~/SVN/guvcview
~/SVN/guvcview$ svn up
~/SVN/guvcview$ ./autogen.sh
~/SVN/guvcview$ make
~/SVN/guvcview$ debuild binary
~/SVN/guvcview# dpkg -i guvcview

Fatto! Semplice no?? Perchè sprecare altre parole?!

enjoy,
giopas

Ma ecco che oggi spunta l’argomento sulla mailing list italiana di Debian, che seguo quasi quotidianamente da più di due anni a questa parte (beh, per molti non è molto).

A questo punto non mi sono trattenuto dal dire la mia.

Riporto di seguito il mio contributo, che non vuole solo limitarsi a Debian, ma a come intendo io il rapporto tra open-source ed aziende.

Fonte

Debian, volendo restare il più possibile democratica in ogni scelta che fa, deve per forza far uso di complesse procedure “burocratiche” al fine di organizzare il lavoro.

E’ semplicemente il prezzo da pagare per poter funzionare.

Certo, tutto sarebbe più semplice con un “despota illuminato”, ma visto che ognuno pensa di poterlo essere, 5000 (a dir poco) despoti illuminati sono uguali a 5000 persone normali… e si ricomincia daccapo a dover fissare delle regole!

L’orizzonte del software libero, e di linux in particolare, sta fortemente cambiando, è vero: le imprese si stanno sempre di più avvicinando ad esso, ovviamente per questioni economiche, portando molti vantaggi in senso di interoperabilità e diffusione dei prodotti liberi.

Ben vengano dunque imprese come Canonical, Red Hat, addiritura Microsoft che assumono ed assumeranno (o potranno assumere) sempre più un ruolo fondamentale per molti di questi progetti/prodotti.

Ma è altresì importante che progetti come Debian continuino ad esistere e a svilupparsi, magari in parte più lentamente degli altri (anche se in realtà per Debian solo le nuove release sono lente, ma non si può dire certo che Debian non sia costantemente al passo con gli sviluppi del software libero!) perché in ogni caso – soprattutto in situazioni di crisi economiche (penso al 2001, alla fine del boom IT) – saranno loro a poter trainare il software libero, proprio perché slegate da logiche strettamente economiche/finanziarie.

Non sono un radicale o fautore del software libero, anzi dico:

1. grazie alle imprese private per l’interesse che stanno mostrando nel software libero e del vantaggio economico che ne stanno traendo (che è un vantaggio virtuoso per tutta la nostra comunità)

ma dico anche:

2. grazie a Debian e a tutte quelle comunità che intendono restare slegate dalle imprese private per la sicurezza che nel medio/lungo periodo ci offrono.

Debian non sta morendo, sta come è logico subendo la concorrenza – concorrenza che è sempre positiva (ad esempio prevedere una roadmap per le release è comunque importante per organizzare il lavoro – come per ogni progetto che si rispetti) – ma non morirà di certo a causa di essa, proprio perchè la sua struttura organizzativa non è legata al mercato economico.

L’unica “ragione di morte” di Debian possono solo essere le lotte interne: per questo esistono, sono state costituite, e devono costantemente essere adattate (e discusse) le regole che la governano.

(IMHO)

enjoy,

giopas

In questa pagina del forum di Adunanza troverete maggiori informazioni

———————

Qui di seguito potrete trovare DUE files .deb per Debian SID (e *forse* per Ubuntu… fatemi sapere se è vero) della versione del 4 luglio 2007.

La prima è compilata normalmente, mentre la seconda include la patch per il minor utilizzo della CPU. E’ una patch sperimentale… quindi testatela e date i vostri riscontri!

La versione per debian Etch non l’ho ancora compilata, dal momento che non ho per una settimana circa accesso al server.

amule-adunanza-cvs_20070704-1_i386.deb

amule-adunanza-cvs_20070704-1_i386_EXPERIMENTAL.deb

enjoy,
giopas

In questa pagina del forum di Adunanza troverete maggiori informazioni

———————

Buongiorno a tutti!

Ho deciso di ricompilare la versione di sviluppo di aMule Adunanza che Mr_Hyde sta aggiornando, fornendo i file binari (.deb) per Debian SID (unstable) e Debian Etch (stable).

In questo modo potremmo procedere più velocemente al testing e ad un aggiornamento del nostro grande MULO.

Ecco i files:

[Debian_SID] amule-adunanza-cvs_20070621-1_i386.deb

[Debian_ETCH] amule-adunanza-cvs_20070621-1_i386.deb

Senza creare una vera e propria repository (non ho banda né tempo a disposizione), mi limiterò – ogni volta che posso – di compilare i sorgenti patchati disponibili qui.

Le opzioni del ./configure sono queste:

./configure --prefix=/usr/local --libdir=/usr/local/lib64 --sysconfdir=/etc --localstatedir=/var --enable-amule-daemon --enable-amulecmd --enable-webserver --enable-wxcas --enable-cas --enable-alc --enable-alcc --with-x --enable-optimize --enable-amule-gui

Da notare il fatto che, mentre per Debian Etch è necessario scaricarsi (come dice il sito di aMule ufficiale) le Wx e compilarsele a mano, per Debian SID basterà aggiungere le due seguenti linee al proprio sources.list:

deb http://www.vollstreckernet.de/debian/ testing wx
deb-src http://www.vollstreckernet.de/debian/ testing wx

Teoricamente potrei anche compilare per per l’architettura ppc (Debian SID), ma solo se qualcuno ne ha bisogno (ho un ibook a 500Mhz, e ci metterebbe una vita!).

Buon testing!

enjoy,
giopas

Ora parleremo di alcuni piccole configurazioni importantissime: configurare l’accesso al server tramite ssh, permettere il lancio del serverX da remoto, configurare il nostro server ftp ed installare webmin.

1. root ed ssh

Basta editare il file /etc/ssh/sshd_config aggiungendo le seguenti righe:

PermitRootLogin no
AllowUsers giopas
DenyUsers root

Basterà un semplice /etc/init.d/sshd restart ed il gioco sarà fatto. Ora un malintenzionato deve: 1. entrare nella nostra rete di Hamachi (nome rete + password) 2. conoscere il nostro nome utente e la password 3. conoscere la password di root… semplice no?

2. lanciare il serverX da ssh

Se provate a lanciare il comando “$ startx” da locale, come abbiamo detto nella prima puntata, non avrete alcun problema a veder comparire il vostro rassicurante desktop. Tuttavia, se lancerete lo stesso comando da remoto, otterrete un semplice… errore!

Ecco un piccolo workaround:

# nano /etc/X11/Xwrapper.config

E cambiare il termine “console” con “anybody”. Semplice ed indolore!

3. configurare il server ftp

Se è vero che il nostro server è ad uso esclusivo casalingo, è anche vero che ad esempio potrei voler lasciar accedere al mio server anche qualche amico fidato tramite ftp.

Per far ciò, prima di tutto creo sul server (questa volta) una nuova rete hamachi (es. giopas-amici), poi creo un utente virtuale sul mio serverino e configuro la nuova home dell’utente (es. host) come cartella di accesso predefinita.

Ecco come fare:

a) aggiungo ad /etc/shells l’opzione seguente “/bin/false”

# echo "bin/false" >> /etc/shells

b) creo un nuovo utente con nome “host”, home “host”, password “host”, shell “/bin/false” e gruppo “host”

useradd host -p host -d /home/ftp -s /bin/false -u 1002 -g host

Se per caso il comando non andasse, usare l’interfaccia grafica

c) creare due cartelle nella nuova home dell’utente virtuale “host” ovviamente da root:

# mkdir /home/ftp/download
# mkdir /home/ftp/upload
# chmod -R 755 /home/ftp/download/
# chmod -R 777 /home/ftp/upload/

d) configuro ora il nostro server ftp editando /etc/proftp.conf ed aggiungendo le linee seguenti

## VALID LOGINS

AllowUser giopas
AllowUser host
DenyALL

### Lock ftphost in his home directory (but not giopas)
DefaultRoot ~ host, !giopas

In questo modo, connettendosi al server ftp con l’utente “host” potrò vedere solo il contenuto della sua home, mentre connettendosi al server ftp con il proprio nome utente (nel mio esempio, giopas) potrò accedere a tutto il file system.

3. installazione di webmin

Per concludere la nostra piccola guida, vedremo come installare webmin, utilissima interfaccia di gestione di tutte le impostazioni del server, tramite pratica interfaccia browser.

a) scaricare il file .deb da questo indirizzo (per alcuni problemi di sicurezza e – se mi ricordo bene – di policy, non troverete il pacchetto nelle repository ufficiali di Debian).

$ wget http://puzzle.dl.sourceforge.net/sourceforge/webadmin/webmin_1.350_all.deb

b) Una volta installato, eseguite da root un semplice “dpkg -i webmin_1.350_all.deb” ed installate anche tutte le librerie collegate.

c) Ora potrete accedere a webmin all’indirizzo e porta (es: https://localhost:8000) riportati dal terminale!

d) ultima cosa: visto che abbiamo aperto un nuovo servizio/porta sul nostro server, ricordiamoci di aggiungere una regola allo script di iptables che abbiamo creato la volta precedente:

echo "### blocco ogni connessione da eth0 verso la porta 8000 (webmin)" >> /etc/network/if-up.d/regole_iptables_avvio ;
echo "iptables -I INPUT -i eth0 -p tcp --dport 8000 -j DROP" >> /etc/network/if-up.d/regole_iptables_avvio

La stessa cosa si sarebbe potuta fare anche da webmin stesso

Ecco pronto il nostro leggerissimo server: sicuro e del tutto configurabile.