http://www.technobuzz.net/21-best-google-android-applications/
http://gizmodo.com/5053280/androids-10-most-exciting-apps
http://blogs.wsj.com/digits/2009/12/22/the-best-android-apps-of-2009/
http://101bestandroidapps.com/
29 décembre 2009
28 décembre 2009
wireless on Fujitsu siemens laptop
Re: wireless on Fujitsu seimens Amilo Li 1718 with ubuntu 9.10
Ok so wireless is working on my laptop and I'm a happy bunny. For any one who ends up here having the same problems these are the steps I used to get it up and running
1. I followed the steps outlined by Momo in this txt file
http://www.edbl.no/karmic/amilo_1718...buntu_9.10.txt
2. Downloaded and installed Acerhk GUI and followed its steps to load acerhk.ko which was incredibly simple because it does it automaticaly
Hope this helps anyone with a similar problem. Just as a little bonus my laptop is 10 degrees cooler at least while running which means it will have a longer life expectancy.
__________________
Ok so wireless is working on my laptop and I'm a happy bunny. For any one who ends up here having the same problems these are the steps I used to get it up and running
1. I followed the steps outlined by Momo in this txt file
http://www.edbl.no/karmic/amilo_1718...buntu_9.10.txt
2. Downloaded and installed Acerhk GUI and followed its steps to load acerhk.ko which was incredibly simple because it does it automaticaly
Hope this helps anyone with a similar problem. Just as a little bonus my laptop is 10 degrees cooler at least while running which means it will have a longer life expectancy.
__________________
15 décembre 2009
24 octobre 2009
Mandriva: retour en grâce par la grâce d'une clé 3 G
Je me suis battu quelques heures avec ma clé 3G Huawei fournie par Mobistar por l'installer sous Ubuntu 8.10 et Debian. Je me suis rappelé que Mandriva faisait sa pub sur un support nickel pour les clefs 3G, c'était vrai, on branche on met le code PIN et une petite config (iew.be) et on est connecté magique... Mandriva reprendrait-il l'avantage en terme de support matériel comme à la fin du siècle passé?
Pour configurer les dépôts il convient de faire un tour ici:
http://easyurpmi.zarb.org/
Pour configurer les dépôts il convient de faire un tour ici:
http://easyurpmi.zarb.org/
05 octobre 2009
Wi-fi chipset intel en mode ETSI
Modifier (Ubuntu 8.10) ou créer (Fedora 10) le fichier /etc/modprobe.d/options pour y rajouter :
options cfg80211 ieee80211_regdom=EU
options cfg80211 ieee80211_regdom=EU
30 septembre 2009
dvb-t
La carte usb DVB-T asus my cinema U3100 Mini est reconnue par ubuntu 8.10
totem lit le flux s'il y a un fichier dvb-channels.conf dans ~/gstreamer-0.10/
La commande pour le créer est:
scan -n -o zap -p /usr/share/doc/dvb-utils/examples/scan/dvb-t/be-St_Pieters_Leeuw > channels.conf
totem lit le flux s'il y a un fichier dvb-channels.conf dans ~/gstreamer-0.10/
La commande pour le créer est:
scan -n -o zap -p /usr/share/doc/dvb-utils/examples/scan/dvb-t/be-St_Pieters_Leeuw > channels.conf
14 juillet 2009
Le plan IT de la RW
Prochaine législature: les petites touches IT de l'Olivier
13 juillet 2009 -- Brigitte Doucet
data news
Pas de pôle I(C)T dans l'accord de gouvernement intervenu, ce week-end, en Région wallonne et Communauté française - mais personne n'en espérait réellement un.
On le savait depuis quelque temps déjà, le 6ème pôle de compétitivité wallon sera orienté écologie et développement durable. Quant à l'ICT, elle demeure considérée comme une technologie 'transversale', destinée à soutenir, de l'intérieur, les divers axes d'activités. Elle n'est toutefois pas absente du texte de l'accord puisqu'on la retrouve à divers étages.
Société de la connaissance
Un chapitre est consacré la "société de la connaissance et de l'information" avec, pour ambition, de "lever toutes les barrières d'ordre éducatif, culturel ou sociologique".
Pour lutter contre la fracture numérique, le gouvernement "s'engage à poursuivre et améliorer la formation aux technologies de l'information et de la communication (TIC), à favoriser l'accès à Internet et à l'équipement, et à promouvoir l'utilisation de logiciels libres et de normes ouvertes." Le nombre d'EPN (espaces publics numériques) sera renforcé.
La formation aux TIC devra être assurée "dès le plus jeune âge" (dès l'enseignement primaire). Le projet CyberClasse se voit ainsi citer dans l'accord de gouvernement. Non pour parler d'une réévaluation ou d'un redimensionnement mais simplement pour constater qu'il devrait améliorer la norme d'équipement des écoles (1 ordinateur par 15 élèves au lieu de 33, jusqu'ici) et pour souligner que les Centres de compétence sont là pour assurer une formation gratuite aux enseignants et directeurs d'école.
Des pistes d'avenir sont néanmoins esquissées :
- poursuite des efforts d'amélioration de la maintenance du matériel usagé dans les écoles,
- développement de la formation des enseignants à l'utilisation des nouveaux outils informatiques,
- promotion de la connectivité haut débit,
- renforcement des formations prodiguées par les Centres de compétence (notamment au bénéfice de la promotion sociale),
- formation des jeunes et moins jeunes à une utilisation critique et sélective d'Internet.
Côté entreprises, l'accord de gouvernement parle de "développer leur compétitivité numérique" et d'"améliorer la progression de l'usage des TIC, en particulier l'e-business". Pour ce faire, l'AWT (agence wallonne des télécommunications) aura pour mission de conseiller davantage PME et indépendants pour faciliter l'accès aux réseaux haut débit et de renforcer son rôle de veille technologique pour les jeunes sociétés actives dans les TIC.
Le réseau fibre à haut débit sera renforcé et le nombre de zonings connectés sera accru.
Un effort sera fourni, d'une part, du côté des échanges et de la collaboration entre entreprises et filières qui développent des produits et services s'appuyant sur l'IT (e-santé, télémédecine, animation 3D...) et, de l'autre, de l'"encouragement" à utiliser les TIC dans les domaines des transports, de la construction, du tourisme, du secteur médical... Une petite phrase qui résonne comme un adoubement du nouveau plan d'action de l'Infopole (cluster TIC wallon) et de la volonté déjà exprimée des divers 'clusters' et autres pôles de compétitivité d'accentuer leurs collaborations.
En matière d'ICT pour entreprises, deux axes semblent avoir la préférence : d'une part, la promotion de l'e-business et, de l'autre, la sécurité dans l'usage des TIC (prévention, sensibilisation, aide à l'investissement dans les protections).
Un paragraphe est par ailleurs consacré aux jeunes pousses (sans distinction de technologies) qui sont l'émanation d'universités, de hautes écoles ou de centres de recherche. Les diverses étapes de leur existence (création, développement, arrivée à maturité) devraient faire l'objet de "mécanismes de soutien (plus) spécifiques."
La promotion du 'libre'
Le secteur public, lui, semble avoir été enjoint de montrer l'exemple en matière d'utilisation de normes ouvertes et de logiciels libres :
- promotion et utilisation, "dans la mesure du possible", de normes ouvertes et logiciels libres dans les administrations publiques, organismes d'intérêt public et cabinets ministériel ;
- développement d'une plate-forme d'échange, de coopération et d'information en matière de logiciels libres et de normes ouvertes entre tous les acteurs publics actifs dans les TIC ;
- promotion de l'usage des logiciels libres auprès des citoyens et entreprises, notamment par des actions de sensibilisation et de formation ;
- promotion et formation à l'utilisation des logiciels libres dans les écoles.
Deux phrases font allusion à l'orientation future de l'informatique des services publics wallons, dont on sait qu'elle traverse une période cruciale après la dénonciation du GIEI et le rapatriement de certaines compétences (voire applications). A l'avenir, lorsque des développements devront encore être faits sur mesure, le gouvernement demandera à être "propriétaire des codes source ou d'en avoir la disponibilité selon une licence libre reconnue."
Les cahiers de charges (toujours pour des développements sur mesure) devront être adaptés de telle sorte à favoriser les candidatures de PME.
A noter aussi l'organisation, par le Conseil de la Politique scientifique Wallonie-Bruxelles, d'un processus de "technology assessment" devant "éclairer les décideurs politiques, notamment les parlementaires, sur les enjeux technologiques et scientifiques."
L'iT en transversal
L'accord de gouvernement signale au passage, mais sans s'y attarder, l'intérêt de voir les nouvelles technologies être davantage mises au service de la mise à l'emploi. Le Forem est ainsi invité à "intensifier l'envoi d'offres d'emploi individualisées par le biais des nouvelles technologies (sms, courriel, ...) et à développer notamment un système de matching entre l'offre et la demande."
On retrouve encore l'ICT citée dans 3 domaines spécifiques :
- le soutien aux exploitations agricoles, où il s'agira de "promouvoir les outils informatiques de gestion technique et économique au sein des exploitations agricoles" ;
- la participation active des aînés à la vie en société, en leur permettant de "s'initier à l'informatique, notamment à l'accès au réseau Internet" ;
- la lutte contre le surendettement, via l'"harmonisation de la gestion informatique des dossiers de services de médiation de dettes."
13 juillet 2009 -- Brigitte Doucet
data news
Pas de pôle I(C)T dans l'accord de gouvernement intervenu, ce week-end, en Région wallonne et Communauté française - mais personne n'en espérait réellement un.
On le savait depuis quelque temps déjà, le 6ème pôle de compétitivité wallon sera orienté écologie et développement durable. Quant à l'ICT, elle demeure considérée comme une technologie 'transversale', destinée à soutenir, de l'intérieur, les divers axes d'activités. Elle n'est toutefois pas absente du texte de l'accord puisqu'on la retrouve à divers étages.
Société de la connaissance
Un chapitre est consacré la "société de la connaissance et de l'information" avec, pour ambition, de "lever toutes les barrières d'ordre éducatif, culturel ou sociologique".
Pour lutter contre la fracture numérique, le gouvernement "s'engage à poursuivre et améliorer la formation aux technologies de l'information et de la communication (TIC), à favoriser l'accès à Internet et à l'équipement, et à promouvoir l'utilisation de logiciels libres et de normes ouvertes." Le nombre d'EPN (espaces publics numériques) sera renforcé.
La formation aux TIC devra être assurée "dès le plus jeune âge" (dès l'enseignement primaire). Le projet CyberClasse se voit ainsi citer dans l'accord de gouvernement. Non pour parler d'une réévaluation ou d'un redimensionnement mais simplement pour constater qu'il devrait améliorer la norme d'équipement des écoles (1 ordinateur par 15 élèves au lieu de 33, jusqu'ici) et pour souligner que les Centres de compétence sont là pour assurer une formation gratuite aux enseignants et directeurs d'école.
Des pistes d'avenir sont néanmoins esquissées :
- poursuite des efforts d'amélioration de la maintenance du matériel usagé dans les écoles,
- développement de la formation des enseignants à l'utilisation des nouveaux outils informatiques,
- promotion de la connectivité haut débit,
- renforcement des formations prodiguées par les Centres de compétence (notamment au bénéfice de la promotion sociale),
- formation des jeunes et moins jeunes à une utilisation critique et sélective d'Internet.
Côté entreprises, l'accord de gouvernement parle de "développer leur compétitivité numérique" et d'"améliorer la progression de l'usage des TIC, en particulier l'e-business". Pour ce faire, l'AWT (agence wallonne des télécommunications) aura pour mission de conseiller davantage PME et indépendants pour faciliter l'accès aux réseaux haut débit et de renforcer son rôle de veille technologique pour les jeunes sociétés actives dans les TIC.
Le réseau fibre à haut débit sera renforcé et le nombre de zonings connectés sera accru.
Un effort sera fourni, d'une part, du côté des échanges et de la collaboration entre entreprises et filières qui développent des produits et services s'appuyant sur l'IT (e-santé, télémédecine, animation 3D...) et, de l'autre, de l'"encouragement" à utiliser les TIC dans les domaines des transports, de la construction, du tourisme, du secteur médical... Une petite phrase qui résonne comme un adoubement du nouveau plan d'action de l'Infopole (cluster TIC wallon) et de la volonté déjà exprimée des divers 'clusters' et autres pôles de compétitivité d'accentuer leurs collaborations.
En matière d'ICT pour entreprises, deux axes semblent avoir la préférence : d'une part, la promotion de l'e-business et, de l'autre, la sécurité dans l'usage des TIC (prévention, sensibilisation, aide à l'investissement dans les protections).
Un paragraphe est par ailleurs consacré aux jeunes pousses (sans distinction de technologies) qui sont l'émanation d'universités, de hautes écoles ou de centres de recherche. Les diverses étapes de leur existence (création, développement, arrivée à maturité) devraient faire l'objet de "mécanismes de soutien (plus) spécifiques."
La promotion du 'libre'
Le secteur public, lui, semble avoir été enjoint de montrer l'exemple en matière d'utilisation de normes ouvertes et de logiciels libres :
- promotion et utilisation, "dans la mesure du possible", de normes ouvertes et logiciels libres dans les administrations publiques, organismes d'intérêt public et cabinets ministériel ;
- développement d'une plate-forme d'échange, de coopération et d'information en matière de logiciels libres et de normes ouvertes entre tous les acteurs publics actifs dans les TIC ;
- promotion de l'usage des logiciels libres auprès des citoyens et entreprises, notamment par des actions de sensibilisation et de formation ;
- promotion et formation à l'utilisation des logiciels libres dans les écoles.
Deux phrases font allusion à l'orientation future de l'informatique des services publics wallons, dont on sait qu'elle traverse une période cruciale après la dénonciation du GIEI et le rapatriement de certaines compétences (voire applications). A l'avenir, lorsque des développements devront encore être faits sur mesure, le gouvernement demandera à être "propriétaire des codes source ou d'en avoir la disponibilité selon une licence libre reconnue."
Les cahiers de charges (toujours pour des développements sur mesure) devront être adaptés de telle sorte à favoriser les candidatures de PME.
A noter aussi l'organisation, par le Conseil de la Politique scientifique Wallonie-Bruxelles, d'un processus de "technology assessment" devant "éclairer les décideurs politiques, notamment les parlementaires, sur les enjeux technologiques et scientifiques."
L'iT en transversal
L'accord de gouvernement signale au passage, mais sans s'y attarder, l'intérêt de voir les nouvelles technologies être davantage mises au service de la mise à l'emploi. Le Forem est ainsi invité à "intensifier l'envoi d'offres d'emploi individualisées par le biais des nouvelles technologies (sms, courriel, ...) et à développer notamment un système de matching entre l'offre et la demande."
On retrouve encore l'ICT citée dans 3 domaines spécifiques :
- le soutien aux exploitations agricoles, où il s'agira de "promouvoir les outils informatiques de gestion technique et économique au sein des exploitations agricoles" ;
- la participation active des aînés à la vie en société, en leur permettant de "s'initier à l'informatique, notamment à l'accès au réseau Internet" ;
- la lutte contre le surendettement, via l'"harmonisation de la gestion informatique des dossiers de services de médiation de dettes."
18 mars 2009
Howto setup an EAP-TLS WPA network with freeradius
A WPA entreprise network secured with EAP/TLS & Freeradius
Introduction
The most important choice to make when implementing WPA entreprise is which flavor of EAP to use. This choice is mainly limited by your client platform. Indeed, the freeradius server licensed under the free GPL license could be made compliant with virtually all EAP method you may dream of. Your wireless access point is EAP agnostic. You only have to verify that it supports WPA entreprise sometimes mentioned as 802.1x by some vendors. It simply passes EAP traffic from clients to servers, without requiring explicit support for any particular EAP subtype.
What your client platform supports is a function both of your client operating system and of its wireless hardware. For example, a Microsoft Windows XP system with an Centrino chipset supports EAP-TLS and PEAP, but EAP-TTLS isn't an easy option if using a Microsoft OS. At the opposite if you run Linux with wpa_supplicant, you have a much wider range of choices available.
Here we choose to use EAP-TLS. EAP-TLS requires client certificates, which in turn requires you to set up a certificate authority (CA). TLS authentication provides strong security thanks to X.509 certificate. In fact it doesn't require that much work to use OpenSSL to create your own CA.
In this howto, Windows XP clients use EAP-TLS to connect to a WPA-enabled access point. The access point, in turn, is configured to authenticate on a FreeRADIUS server running Linux (Debian Lenny).
Freeradius with EAP-TLS/TTLS/PEAP support
Debian's freeRadius package is built without support for EAP/TLS/TTLS/PEAP because of the licensing problems of the OpenSSL library. We want to implement 802.1x network authentication with strong security, so we need it. We will build Debian package (lenny, stable at time of writing 10 March 2009) linked to libssl and with EAP/TLS/TTLS/PEAP support compiled in.
I suppose you made a minimal installation of lenny and you added a minimal gnome environment.
$ apt-get install x-window-system-core
$ apt-get install gnome-core synaptic
Then in order to build the missing packages you need to install dpkg-dev and fakeroot (to limit root access)
$ apt-get install dpkg-dev fakeroot
Download the newest source package (orig.tar.gz), Debian diffs (diff.gz) and description file (dsc) from the freeradius package page. The version I tested the procedure with is freeradius-2.0.4+dfsg
Unpack the source and switch to the resulting directory like this:
# dpkg-source -x *.dsc
dpkg-source: extracting freeradius in freeradius-2.0.4+dfsg
dpkg-source: unpacking freeradius_2.0.4+dfsg-6.diff.gz
dpkg-source: applying ./freeradius_2.0.4+dfsg-6.diff.gz
# cd freeradius-*
There are two files that must be edited in order to successfully build the package:
1. Edit debian/rules, search for eap and change every mentioning of --without-rlm_eap-* to --with-rlm_eap-* excepted --without-rlm_eap_ikev2, --without-rlm_eap_tnc --without-rlm_sql_oracle --without-rlm_sql_unixodbc --without-rlm_otp
A few lines below, in the same file, replace --without-openssl with --with-openssl.
So it should look like:
--with-rlm_eap_tls \
--with-rlm_eap_ttls \
--with-rlm_eap_peap \
--without-rlm_eap_tnc \
--without-rlm_otp \
--with-rlm_sql_postgresql_lib_dir=`pg_config --libdir`\
--with-rlm_sql_postgresql_include_dir=`pg_config --includedir` \
--with-openssl \
--without-rlm_eap_ikev2 \
--without-rlm_sql_oracle \
--without-rlm_sql_unixodbc \
Still editing the same file, find the following code and comment it entirely:
for pkg in ${pkgs} ; do \
if dh_shlibdeps -p $$pkg -- -O 2>/dev/null | grep -q libssl; then \
echo "$$pkg links to openssl" ;\
exit 1 ;\
fi ;\
done
2. Finally, edit debian/control and at the end of the line starting with Build-Depends: add , libssl-dev
Finally, I needed to install some packages before running "dpkg-buildpackage -rfakeroot":
# apt-get install libssl-dev debhelper libgdbm-dev libiodbc2-dev libkrb5-dev libldap2-dev libltdl3-dev libmysqlclient15-dev libpam0g-dev libpcap-dev libperl-dev libpq-dev libsasl2-dev libsnmp-dev python-dev
You can now build new packages with EAP/TLS/TTLS/PEAP support like this:
# dpkg-buildpackage -rfakeroot
If everything goes well, you'll find 10 debian packages in the parent directory which you can now install. Don't forget to hold newly installed packages in your package manager. Otherwise new official versions (without EAP/TLS/TTLS/PEAP support) should overwrite your custom built packages when upgrading.
A way to achieve the "hold" is by using dpkg
Put a package on hold
echo “package hold” | dpkg --set-selections
Example
echo “freeradius hold” | dpkg --set-selections
Remove the hold
echo “package install” | dpkg --set-selections
Example
echo “freeradius install” | dpkg --set-selections
Knowing the status of your packages
dpkg --set-selections
Now I show you what's happening when installing the newly created packages on a frenchspeaking lenny server (hostname: hp-debian-stable.multitel.be)
hp-debian-stable:/home/hanoteau# dpkg --install freeradius-common_2.0.4+dfsg-6_all.deb
Sélection du paquet freeradius-common précédemment désélectionné.
(Lecture de la base de données... 99926 fichiers et répertoires déjà installés.)
Dépaquetage de freeradius-common (à partir de freeradius-common_2.0.4+dfsg-6_all.deb) ...
Paramétrage de freeradius-common (2.0.4+dfsg-6) ...
Ajout de l'utilisateur freerad au groupe shadow
Traitement des actions différées (« triggers ») pour « man-db »...
hp-debian-stable:/home/hanoteau# dpkg --install libfreeradius2_2.0.4+dfsg-6_i386.deb
Sélection du paquet libfreeradius2 précédemment désélectionné.
(Lecture de la base de données... 100311 fichiers et répertoires déjà installés.)
Dépaquetage de libfreeradius2 (à partir de libfreeradius2_2.0.4+dfsg-6_i386.deb) ...
Paramétrage de libfreeradius2 (2.0.4+dfsg-6) ...
hp-debian-stable:/home/hanoteau# dpkg --install freeradius_2.0.4+dfsg-6_i386.deb
(Lecture de la base de données... 100317 fichiers et répertoires déjà installés.)
Préparation du remplacement de freeradius 2.0.4+dfsg-6 (en utilisant freeradius_2.0.4+dfsg-6_i386.deb) ...
Dépaquetage de la mise à jour de freeradius ...
Paramétrage de freeradius (2.0.4+dfsg-6) ...
suppression du / final
suppression du / final
suppression du / final
Starting FreeRADIUS daemon: freeradius.
Now Freeradius is supposed to run, let's go further
Creating a Certificate Authority
Before we configure FreeRADIUS, we need to create some certificates. And before we create any certificates, we must create our CA.
A CA is a system that acts as the root of a public key infrastructure. It's the central authority that guarantees, by way of digital signatures, the authenticity of all certificates issued in your organization. It also periodically issues certificate revocation lists (CRLs), lists of certificates the CA no longer guarantees, for example, certificates issued to people who've left the organization, servers that are no longer on-line and so on.
None of this requires your CA to act as an actual server; in fact, it's better if it doesn't. For a CA to be trustworthy, it must be protected carefully from misuse. So your CA should be on a not permanently connected server or on a virtual machine.I recommend you virtual box OSE for freely creating virtual machines.
If you already have a CA that you've used to create certificates for Web servers or other applications that use TLS then just use it for WPA too. If not, here's how to create a CA. First, make sure your designated CA system has OpenSSL installed. OpenSSL is a standard package on all popular Linux distributions, not to mention BSD. One quick way to make sure you have OpenSSL is to issue the command which openssl. This command returns the path to your OpenSSL command, if it's installed.
On debian Lenny the path is: /usr/bin/openssl
Next, change your working directory to wherever your system keeps OpenSSL's configuration and certificate files. On debian lenny, this is /etc/ssl.
Now, open the file openssl.cnf with your text editor of choice, do you know vim? We will tweak some default settings so as to make certificate creation speedier later on. Feel free to adapt this to your special needs or go to the next step if you are in a hurry.
Changes to openssl.cnf for Optimal Certificate Creation
# First we change the CA root path in the CA_default
# section to reflect the CA we're about to create
[ CA_default ]
dir = ./jhCA # Where everything is kept by default ./demoCA
# The following lines are further down in openssl.cnf:
countryName_default = Be
stateOrProvinceName_default = Hainaut
0.organizationName_default = Multitel ASBL
Next, we should edit the CA creation script to change our CA's root directory to something other than demoCA, that is, to match the dir variable we just changed in openssl.cnf. I use the script CA.sh, which on Debian lenny systems is located in /usr/share/ssl/misc. The line you need to change is CATOP=./jhCA.
If you changed your working directory to edit this file, change back to your SSL configuration directory, for example, /etc/ssl. From there, run the CA.sh script with the -newca option, for example, /usr/lib/ssl/misc/CA.sh -newca. You then are prompted to create a new root certificate and to type a passphrase for its private key. Choose a difficult-to-guess passphrase, and write it down in a safe place—if you forget it, you'll be unable to use your CA.
If you really want to follow this howto witout needing any personal input feel free to type the proposed password. Doing so you will have an unsecure EAP-TLS test infrastructure.
passphrase: strongpasswordbebete
challenge password: telematique
After the script is done, your SSL configuration directory should contain a new directory, jhCA in our example. At the root level of this directory is your new CA's public certificate; by default this file is named cacert.pem. You need to copy this file to your FreeRADIUS server and to each wireless client.
There's one more thing you need to do before creating certificates if you've got Windows XP wireless clients. Windows XP expects certain attributes in server and client certificates, so you need to create a file called xpextensions that contains the lines shown below.
Contents of xpextensions
[xpclient_ext]
extendedKeyUsage=1.3.6.1.5.5.7.3.2
[xpserver_ext]
extendedKeyUsage=1.3.6.1.5.5.7.3.1
It should be in the same directory as openssl.cnf.
In EAP-TLS, a wireless client and your RADIUS server mutually authenticate each other. They present each other with their respective certificates and cryptographically verify that those certificates were signed by your organization's certificate authority. In some ways, this is an elegant and simple way to handle authentication. After you install the CA's public certificate on the FreeRADIUS server, you don't need to configure any other client information explicitly, such as user names, passwords and so on.
That doesn't mean EAP-TLS is less work than user name-password schemes, however. You still need to use OpenSSL to create certificates for all your users and copy those certificates over to them. You also need to ensure that everyone has a copy of the root CA certificate installed in the proper place.
Creating Certificates
For EAP-TLS, you need at least two certificates in addition to your CA certificate, a server certificate for your FreeRADIUS server and one client certificate for each wireless client on your network. Creating certificates is a three-step process:
Generate a signing request, that is, an unsigned certificate.
Sign the signing request with your CA key.
Copy the signed certificate to the host on which it will be used.
Let's start by creating a server certificate signing request using OpenSSL's req command:
$ openssl req -new -nodes -keyout server_key.pem -out server_req.pem -days 730 -config ./openssl.cnf
(challenge password : telematique)
This command creates the files server_req.pem, which contains the actual request—an unsigned certificate—and server_key.pem, its passphrase-less private key. First, though, you are prompted for your organization's Country Code, State and so on, much of which can use the default values defined in openssl.conf. Pay special attention, however, to Common Name. When prompted for this, type the fully qualified domain name of your server, for example, hp-debian-stable.multitel.be.
Next, let's use our CA key to sign the request by using OpenSSL's ca command:
$ openssl ca -config ./openssl.cnf \
-policy policy_anything -out server_cert.pem \
-extensions xpserver_ext -extfile ./xpextensions \
-infiles ./server_req.pem
(strongpasswordbebete)
This command reads the file server_req.pem and, after prompting for your CA key's passphrase, saves a signed version of it plus its corresponding private key to the file server_cert.pem. Notice the -extensions and -extfile options—this is why earlier we created the file xpextensions.
Open your signed certificate with the text editor of your choice and delete everything before the line -----BEGIN CERTIFICATE-----. Concatenate it and your key into a single file, like this:
$ cp server_cert.pem server_cert.pem-backup
$ cat server_key.pem server_cert.pem > \
server_keycert.pem
(strongpasswordbebete)
Now we've got a server certificate with a key that we can copy over to our FreeRADIUS server. Its private key isn't password-protected, however, so be sure to delete any extraneous copies after you've got it in place.
Now we need to create a client certificate signing request. The OpenSSL command to do this is similar to that used to create server certificates:
$ openssl req -new -keyout client_key.pem \
-out client_req.pem -days 730 -config ./openssl.cnf
As you can see, we're writing our signing request and key to the files client_req.pem and client_key, respectively. Unlike with the server signing requests, however, we're omitting the -nodes option. Therefore, when you run this command, you are prompted for a passphrase with which the certificate's private key can be encrypted.
Enter PEM pass phrase: devil1
Next we sign the client certificate's signing request:
$ openssl ca -config ./openssl.cnf \
-policy policy_anything -out client_cert.pem \
-extensions xpclient_ext -extfile ./xpextensions \
-infiles ./client_req.pem
(challenge password : telematique1)
Again, this is similar to the equivalent command for our server, except this time the -extensions command references a different entry in xpextensions. Also, if your clients run Linux, you should delete the extraneous stuff in the certificate, like you did with server_cert.pem. You then either can leave the certificate and key files separate or concatenate them. From there, copy your client certificate file(s) to your Linux client system.
If your certificate is to be used by a Windows XP client, you have one more step to take. You need to convert the certificate file(s) to a PKCS12-format file, with this command:
$ openssl pkcs12 -export -in client_cert.pem \
-inkey client_key.pem -out client_cert.p12 -clcerts
(enter passphrase for ./jhCA/private/cakey.pem devil1)
You are prompted for client_key.pem's passphrase and then for a new passphrase for the new file; you can use the same password as before if you like. You may be tempted simply to press Enter instead, especially given that the WPA supplicant in Windows XP works only when you store its certificates without passphrases. It could be dangerous to move private keys around networks unprotected, so It would be good practice if you remove the passphrase after this file is copied safely over to your Windows XP client.
The resulting file, in this example client_cert.p12, contains both your signed certificate and its private key. Copy it to your Windows XP client system.
So we have generated server and client certificates and transferred them to their respective hosts. Now we need to configure FreeRADIUS, our access point and our wireless clients.
The tasks at hand are:
To install the server and CA certificates we created last time onto our FreeRADIUS server.
To configure FreeRADIUS to use these certificates with EAP-TLS to authenticate users for our access point.
To configure our access point to redirect authentication to our FreeRADIUS server.
To install the client and CA certificates we created last time onto a Windows XP client and configure it to use WPA when connecting to the WLAN.
Configuring the freeradius server
We created three X.509 digital certificates: a certificate authority certificate, called cacert.pem; one server certificate, called server_keycert.pem; and a client certificate, called client_cert.p12. The server and client files contain both a certificate and its private key, so each of these must be handled carefully. The CA certificate, however, is stored separately from its key, so you can distribute cacert.pem freely.
FreeRADIUS stores its configuration files in /etc/freeradius/ in Debian lenny. This directory contains a subdirectory, certs/—this, naturally, is where you need to copy your CA certificate and your server certificate/key. Make sure that cacert.pem is owned by the user root and that its permissions are set to -r--r--r--.
server_keycert.pem, on the other hand, should be owned by the user freerad and its permissions set to -r--------.
cp /etc/ssl/jhCA/cacert.pem /etc/freeradius/certs/cacert.pem
cp /etc/ssl/server_keycert.pem /etc/freeradius/certs/server_keycert.pem
Hereafter, the listing shows the long directory listings for these two files.
-r--r--r-- 1 root freerad 1294 2009-02-10 01:05 cacert.pem
-r-------- 1 freerad freerad 1894 2009-02-10 01:00 server_keycert.pem
You also should make sure that the file /var/log/freeradius/radius.log and the directory /var/run/freeradius/ are writable by freerad. Both radius.log and freeradius/ may be owned by freerad.
Before we edit freeradius' configuration files, we need to create two files that freeradius must have in order to use TLS. The first is a Diffie-Hellman parameters file, or dh file, which is used for negotiating TLS session keys. To create a dh file, change your working directory to /etc/freeradius/certs/ directory and issue this command:
# openssl dhparam -check -text -5 512 -out dh
The second file you need is a data file that contains a random bitstream that also is used in TLS operations. From within certs, run this command:
# dd if=/dev/urandom of=random count=2
Both of these files need to be readable by the user freerad, but they should not be writable by anybody.
# chown freerad dh
# chmod o-w dh
We're finally ready to configure freeradius. You may be afraid when you see the long list of files in /etc/freeradius, but don't be. For WPA with EAP-TLS, we need to edit only three files: radiusd.conf, eap.conf and clients.conf.
In radiusd.conf, all we need to do is verify the user and group accounts that the radiusd process runs as. By default these are inherited from whatever user starts the dæmon. If you run radiusd from a startup script, this is root; however, you definitely do not want to run radiusd as root. Therefore, you should set the user and group parameters in radiusd.conf, both set to freerad, as shown below.
Two Parameters to verify in radiusd.conf
user = freerad
group = freerad
Naturally you can choose different nonprivileged user and group accounts instead of freerad and freerad, but if you do so, you need to adjust the ownerships and permissions on the certificate files we created earlier. Regardless, make sure your nonprivileged user's entry in /etc/password sets the user's shell to a non-shell, such as /bin/false or /bin/true—this account should not be usable for SSH, telnet or similar programs. For that matter, make sure both the user and group accounts exist in the first place, and create them if they don't.
Other parameters may be set in radiusd.conf, but these really are the most important parameters we have to check.
The next file we need to edit is eap.conf; here's where the real heavy lifting occurs. Listing below shows the lines you need to edit in eap.conf.
Changes in eap.conf
eap {
# There are several generic EAP parameters you can
# set here, but the important one for our purposes
# is default_eap_type:
default_eap_type = tls
# Next come parameters for specific EAP types. Since
# we're going to use EAP-TLS, the tls{} section is
# the one we care about:
tls {
#
# These is used to simplify later configurations.
#
certdir = ${confdir}/certs
cadir = ${confdir}/certs
private_key_password = whatever
private_key_file = ${certdir}/server_keycert.pem
# If Private key & Certificate are located in
# the same file, then private_key_file &
# certificate_file must contain the same file
# name.
#
# If CA_file (below) is not used, then the
# certificate_file below MUST include not
# only the server certificate, but ALSO all
# of the CA certificates used to sign the
# server certificate.
certificate_file = ${certdir}/server_keycert.pem
# Trusted Root CA list
#
# ALL of the CA's in this list will be trusted
# to issue client certificates for authentication.
#
# In general, you should use self-signed
# certificates for 802.1x (EAP) authentication.
# In that case, this CA file should contain
# *one* CA certificate.
#
# This parameter is used only for EAP-TLS,
# when you issue client certificates. If you do
# not use client certificates, and you do not want
# to permit EAP-TLS authentication, then delete
# this configuration item.
CA_file = ${cadir}/cacert.pem
#
# For DH cipher suites to work, you have to
# run OpenSSL to create the DH file first:
#
# openssl dhparam -out certs/dh 1024
#
dh_file = ${certdir}/dh
random_file = ${certdir}/random
#
# This can never exceed the size of a RADIUS
# packet (4096 bytes), and is preferably half
# that, to accomodate other attributes in
# RADIUS packet. On most APs the MAX packet
# length is configured between 1500 - 1600
# In these cases, fragment size should be
# 1024 or less.
#
fragment_size = 1024
# include_length is a flag which is
# by default set to yes If set to
# yes, Total Length of the message is
# included in EVERY packet we send.
# If set to no, Total Length of the
# message is included ONLY in the
# First packet of a fragment series.
#
include_length = yes
# Check the Certificate Revocation List
#
# 1) Copy CA certificates and CRLs to same directory.
# 2) Execute 'c_rehash'.
# 'c_rehash' is OpenSSL's command.
# 3) uncomment the line below.
# 5) Restart radiusd
# check_crl = yes
# CA_path = /path/to/directory/with/ca_certs/and/crls/
#
# If check_cert_issuer is set, the value will
# be checked against the DN of the issuer in
# the client certificate. If the values do not
# match, the cerficate verification will fail,
# rejecting the user.
#
# check_cert_issuer = "/C=GB/ST=Berkshire/L=Newbury/O=My Company Ltd"
#
# If check_cert_cn is set, the value will
# be xlat'ed and checked against the CN
# in the client certificate. If the values
# do not match, the certificate verification
# will fail rejecting the user.
#
# This check is done only if the previous
# "check_cert_issuer" is not set, or if
# the check succeeds.
#
check_cert_cn = %{User-Name}
#
# Set this option to specify the allowed
# TLS cipher suites. The format is listed
# in "man 1 ciphers".
cipher_list = "DEFAULT"
#
# This configuration entry should be deleted
# once the server is running in a normal
# configuration. It is here ONLY to make
# initial deployments easier
# make_cert_command = "${certdir}/bootstrap"
}
}
We have specified a server-key passphrase with the private_key_password parameter. This actually should be empty if you created your server certificate and key with OpenSSL's -nodes option.
Make sure that eap.conf is owned and readable only by root . This may seem paradoxical doesn't freerad need to be able to read configuration files? But, if you start the freeradius daemon as root, it reads its configuration files, including radiusd.conf, eap.conf and clients.conf, before demoting itself to freerad.
Finally, you need to create an entry for your access point in clients.conf. The listing below shows such an entry for a 3com 7760 a/b/g Access Point (default IP address is 169.254.2.2 when no DHCP server is answering its request).
Access Point Entry in clients.conf
client 169.254.2.2/32 {
secret = testing123
shortname = liv1
}
The client statement specifies the access point's IP address. Its secret parameter specifies a string that your access point uses as an encryption key for all queries it sends to your FreeRADIUS server. shortname simply is an alias for your access point to be used in log entries and so on.
You now can (re)start freeradius by using the rc.radiusd script, for e0xample, rc.radiusd start or by typing freeradius -X -f.
Configuring the Access Point
The next step is the easiest part of this entire process: configure your wireless access point to use WPA and to point to your FreeRADIUS server. This requires only two pieces of information, the RADIUS secret you entered in your FreeRADIUS server's clients.conf file and the IP address of your FreeRADIUS server.
How you present those two pieces of information to your access point depends on your particular hardware and software. The access point used in this howto is a 3com 7760 configuring it via http is a piece of cake.
If your access point and RADIUS server are separated by a firewall, you need to allow the access point to reach the RADIUS server on UDP ports 1812 and 1813. Doing so also allows the RADIUS server to send packets back from those ports.
Configuring Windows XP Clients
Configuring a Windows XP wireless client to use your WPA-enabled access point.
In summary, you need to:
Run the command mmc from Start→Run....
In Microsoft Management Console, select File→Add/Remove Snap-in, add the Certificates snap-in and set it to manage certificates for My user account and, on the next screen, only for the Local computer.
Copy your CA (cacert.pem) certificate to your Windows system's hard drive, for example, to C:\cacert.pem.
From within MMC, expand Console Root and Certificates - Current User and right-click on Trusted Root Certification Authorities. In the pop-up menu, select All Tasks→Import. Tell the subsequent wizard to import the file C:\cacert.pem and to store it in Trusted Root Certification Authorities.
Copy your client certificate/key file to your Windows system, for example, to C:\client_cert.p12.
From within MMC→Console Root→Certificates, expand Personal and right-click on Certificates. In the pop-up menu, select All Tasks→Import. Tell the subsequent wizard to import the file C:\client_cert.p12.
The certificate-import wizard then prompts you for the certificate's passphrase. In the same dialog, it offers the option to enable strong private key protection. Unfortunately, enabling this breaks WPA, so be sure to leave this option unchecked. Also, leave the option to mark this key as exportable unchecked—you're better off backing up the password-protected file you just imported rather than allowing the imported nonprotected version to be exportable.
In the subsequent screen, let the wizard Automatically select the certificate store.
Now your Windows XP system is ready to go—all that remains is to create a wireless network profile. This, however, varies depending on your wireless card's drivers and which Windows XP Service Pack you're running. According to my little experience on using WPA entreprise on Windows XP, SP2 is a minimal requisite if you want a quite functional and stable connection. I set Network Authentication to WPA, Data encryption to TKIP and EAP type to Smart Card or other Certificate. Windows automatically determined which client certificate I used—this is because we took pains to create a client certificate that references Windows XP's extended attributes
.
After you configure your wireless network profile, your Windows system should connect automatically to your access point and negotiate a WPA connection. If this succeeds, Network Connections should show a status of Authentication succeeded for your Wireless Network Connection entry.
A WPA entreprise network secured with EAP/TLS & Freeradius
Introduction
The most important choice to make when implementing WPA entreprise is which flavor of EAP to use. This choice is mainly limited by your client platform. Indeed, the freeradius server licensed under the free GPL license could be made compliant with virtually all EAP method you may dream of. Your wireless access point is EAP agnostic. You only have to verify that it supports WPA entreprise sometimes mentioned as 802.1x by some vendors. It simply passes EAP traffic from clients to servers, without requiring explicit support for any particular EAP subtype.
What your client platform supports is a function both of your client operating system and of its wireless hardware. For example, a Microsoft Windows XP system with an Centrino chipset supports EAP-TLS and PEAP, but EAP-TTLS isn't an easy option if using a Microsoft OS. At the opposite if you run Linux with wpa_supplicant, you have a much wider range of choices available.
Here we choose to use EAP-TLS. EAP-TLS requires client certificates, which in turn requires you to set up a certificate authority (CA). TLS authentication provides strong security thanks to X.509 certificate. In fact it doesn't require that much work to use OpenSSL to create your own CA.
In this howto, Windows XP clients use EAP-TLS to connect to a WPA-enabled access point. The access point, in turn, is configured to authenticate on a FreeRADIUS server running Linux (Debian Lenny).
Freeradius with EAP-TLS/TTLS/PEAP support
Debian's freeRadius package is built without support for EAP/TLS/TTLS/PEAP because of the licensing problems of the OpenSSL library. We want to implement 802.1x network authentication with strong security, so we need it. We will build Debian package (lenny, stable at time of writing 10 March 2009) linked to libssl and with EAP/TLS/TTLS/PEAP support compiled in.
I suppose you made a minimal installation of lenny and you added a minimal gnome environment.
$ apt-get install x-window-system-core
$ apt-get install gnome-core synaptic
Then in order to build the missing packages you need to install dpkg-dev and fakeroot (to limit root access)
$ apt-get install dpkg-dev fakeroot
Download the newest source package (orig.tar.gz), Debian diffs (diff.gz) and description file (dsc) from the freeradius package page. The version I tested the procedure with is freeradius-2.0.4+dfsg
Unpack the source and switch to the resulting directory like this:
# dpkg-source -x *.dsc
dpkg-source: extracting freeradius in freeradius-2.0.4+dfsg
dpkg-source: unpacking freeradius_2.0.4+dfsg-6.diff.gz
dpkg-source: applying ./freeradius_2.0.4+dfsg-6.diff.gz
# cd freeradius-*
There are two files that must be edited in order to successfully build the package:
1. Edit debian/rules, search for eap and change every mentioning of --without-rlm_eap-* to --with-rlm_eap-* excepted --without-rlm_eap_ikev2, --without-rlm_eap_tnc --without-rlm_sql_oracle --without-rlm_sql_unixodbc --without-rlm_otp
A few lines below, in the same file, replace --without-openssl with --with-openssl.
So it should look like:
--with-rlm_eap_tls \
--with-rlm_eap_ttls \
--with-rlm_eap_peap \
--without-rlm_eap_tnc \
--without-rlm_otp \
--with-rlm_sql_postgresql_lib_dir=`pg_config --libdir`\
--with-rlm_sql_postgresql_include_dir=`pg_config --includedir` \
--with-openssl \
--without-rlm_eap_ikev2 \
--without-rlm_sql_oracle \
--without-rlm_sql_unixodbc \
Still editing the same file, find the following code and comment it entirely:
for pkg in ${pkgs} ; do \
if dh_shlibdeps -p $$pkg -- -O 2>/dev/null | grep -q libssl; then \
echo "$$pkg links to openssl" ;\
exit 1 ;\
fi ;\
done
2. Finally, edit debian/control and at the end of the line starting with Build-Depends: add , libssl-dev
Finally, I needed to install some packages before running "dpkg-buildpackage -rfakeroot":
# apt-get install libssl-dev debhelper libgdbm-dev libiodbc2-dev libkrb5-dev libldap2-dev libltdl3-dev libmysqlclient15-dev libpam0g-dev libpcap-dev libperl-dev libpq-dev libsasl2-dev libsnmp-dev python-dev
You can now build new packages with EAP/TLS/TTLS/PEAP support like this:
# dpkg-buildpackage -rfakeroot
If everything goes well, you'll find 10 debian packages in the parent directory which you can now install. Don't forget to hold newly installed packages in your package manager. Otherwise new official versions (without EAP/TLS/TTLS/PEAP support) should overwrite your custom built packages when upgrading.
A way to achieve the "hold" is by using dpkg
Put a package on hold
echo “package hold” | dpkg --set-selections
Example
echo “freeradius hold” | dpkg --set-selections
Remove the hold
echo “package install” | dpkg --set-selections
Example
echo “freeradius install” | dpkg --set-selections
Knowing the status of your packages
dpkg --set-selections
Now I show you what's happening when installing the newly created packages on a frenchspeaking lenny server (hostname: hp-debian-stable.multitel.be)
hp-debian-stable:/home/hanoteau# dpkg --install freeradius-common_2.0.4+dfsg-6_all.deb
Sélection du paquet freeradius-common précédemment désélectionné.
(Lecture de la base de données... 99926 fichiers et répertoires déjà installés.)
Dépaquetage de freeradius-common (à partir de freeradius-common_2.0.4+dfsg-6_all.deb) ...
Paramétrage de freeradius-common (2.0.4+dfsg-6) ...
Ajout de l'utilisateur freerad au groupe shadow
Traitement des actions différées (« triggers ») pour « man-db »...
hp-debian-stable:/home/hanoteau# dpkg --install libfreeradius2_2.0.4+dfsg-6_i386.deb
Sélection du paquet libfreeradius2 précédemment désélectionné.
(Lecture de la base de données... 100311 fichiers et répertoires déjà installés.)
Dépaquetage de libfreeradius2 (à partir de libfreeradius2_2.0.4+dfsg-6_i386.deb) ...
Paramétrage de libfreeradius2 (2.0.4+dfsg-6) ...
hp-debian-stable:/home/hanoteau# dpkg --install freeradius_2.0.4+dfsg-6_i386.deb
(Lecture de la base de données... 100317 fichiers et répertoires déjà installés.)
Préparation du remplacement de freeradius 2.0.4+dfsg-6 (en utilisant freeradius_2.0.4+dfsg-6_i386.deb) ...
Dépaquetage de la mise à jour de freeradius ...
Paramétrage de freeradius (2.0.4+dfsg-6) ...
suppression du / final
suppression du / final
suppression du / final
Starting FreeRADIUS daemon: freeradius.
Now Freeradius is supposed to run, let's go further
Creating a Certificate Authority
Before we configure FreeRADIUS, we need to create some certificates. And before we create any certificates, we must create our CA.
A CA is a system that acts as the root of a public key infrastructure. It's the central authority that guarantees, by way of digital signatures, the authenticity of all certificates issued in your organization. It also periodically issues certificate revocation lists (CRLs), lists of certificates the CA no longer guarantees, for example, certificates issued to people who've left the organization, servers that are no longer on-line and so on.
None of this requires your CA to act as an actual server; in fact, it's better if it doesn't. For a CA to be trustworthy, it must be protected carefully from misuse. So your CA should be on a not permanently connected server or on a virtual machine.I recommend you virtual box OSE for freely creating virtual machines.
If you already have a CA that you've used to create certificates for Web servers or other applications that use TLS then just use it for WPA too. If not, here's how to create a CA. First, make sure your designated CA system has OpenSSL installed. OpenSSL is a standard package on all popular Linux distributions, not to mention BSD. One quick way to make sure you have OpenSSL is to issue the command which openssl. This command returns the path to your OpenSSL command, if it's installed.
On debian Lenny the path is: /usr/bin/openssl
Next, change your working directory to wherever your system keeps OpenSSL's configuration and certificate files. On debian lenny, this is /etc/ssl.
Now, open the file openssl.cnf with your text editor of choice, do you know vim? We will tweak some default settings so as to make certificate creation speedier later on. Feel free to adapt this to your special needs or go to the next step if you are in a hurry.
Changes to openssl.cnf for Optimal Certificate Creation
# First we change the CA root path in the CA_default
# section to reflect the CA we're about to create
[ CA_default ]
dir = ./jhCA # Where everything is kept by default ./demoCA
# The following lines are further down in openssl.cnf:
countryName_default = Be
stateOrProvinceName_default = Hainaut
0.organizationName_default = Multitel ASBL
Next, we should edit the CA creation script to change our CA's root directory to something other than demoCA, that is, to match the dir variable we just changed in openssl.cnf. I use the script CA.sh, which on Debian lenny systems is located in /usr/share/ssl/misc. The line you need to change is CATOP=./jhCA.
If you changed your working directory to edit this file, change back to your SSL configuration directory, for example, /etc/ssl. From there, run the CA.sh script with the -newca option, for example, /usr/lib/ssl/misc/CA.sh -newca. You then are prompted to create a new root certificate and to type a passphrase for its private key. Choose a difficult-to-guess passphrase, and write it down in a safe place—if you forget it, you'll be unable to use your CA.
If you really want to follow this howto witout needing any personal input feel free to type the proposed password. Doing so you will have an unsecure EAP-TLS test infrastructure.
passphrase: strongpasswordbebete
challenge password: telematique
After the script is done, your SSL configuration directory should contain a new directory, jhCA in our example. At the root level of this directory is your new CA's public certificate; by default this file is named cacert.pem. You need to copy this file to your FreeRADIUS server and to each wireless client.
There's one more thing you need to do before creating certificates if you've got Windows XP wireless clients. Windows XP expects certain attributes in server and client certificates, so you need to create a file called xpextensions that contains the lines shown below.
Contents of xpextensions
[xpclient_ext]
extendedKeyUsage=1.3.6.1.5.5.7.3.2
[xpserver_ext]
extendedKeyUsage=1.3.6.1.5.5.7.3.1
It should be in the same directory as openssl.cnf.
In EAP-TLS, a wireless client and your RADIUS server mutually authenticate each other. They present each other with their respective certificates and cryptographically verify that those certificates were signed by your organization's certificate authority. In some ways, this is an elegant and simple way to handle authentication. After you install the CA's public certificate on the FreeRADIUS server, you don't need to configure any other client information explicitly, such as user names, passwords and so on.
That doesn't mean EAP-TLS is less work than user name-password schemes, however. You still need to use OpenSSL to create certificates for all your users and copy those certificates over to them. You also need to ensure that everyone has a copy of the root CA certificate installed in the proper place.
Creating Certificates
For EAP-TLS, you need at least two certificates in addition to your CA certificate, a server certificate for your FreeRADIUS server and one client certificate for each wireless client on your network. Creating certificates is a three-step process:
Generate a signing request, that is, an unsigned certificate.
Sign the signing request with your CA key.
Copy the signed certificate to the host on which it will be used.
Let's start by creating a server certificate signing request using OpenSSL's req command:
$ openssl req -new -nodes -keyout server_key.pem -out server_req.pem -days 730 -config ./openssl.cnf
(challenge password : telematique)
This command creates the files server_req.pem, which contains the actual request—an unsigned certificate—and server_key.pem, its passphrase-less private key. First, though, you are prompted for your organization's Country Code, State and so on, much of which can use the default values defined in openssl.conf. Pay special attention, however, to Common Name. When prompted for this, type the fully qualified domain name of your server, for example, hp-debian-stable.multitel.be.
Next, let's use our CA key to sign the request by using OpenSSL's ca command:
$ openssl ca -config ./openssl.cnf \
-policy policy_anything -out server_cert.pem \
-extensions xpserver_ext -extfile ./xpextensions \
-infiles ./server_req.pem
(strongpasswordbebete)
This command reads the file server_req.pem and, after prompting for your CA key's passphrase, saves a signed version of it plus its corresponding private key to the file server_cert.pem. Notice the -extensions and -extfile options—this is why earlier we created the file xpextensions.
Open your signed certificate with the text editor of your choice and delete everything before the line -----BEGIN CERTIFICATE-----. Concatenate it and your key into a single file, like this:
$ cp server_cert.pem server_cert.pem-backup
$ cat server_key.pem server_cert.pem > \
server_keycert.pem
(strongpasswordbebete)
Now we've got a server certificate with a key that we can copy over to our FreeRADIUS server. Its private key isn't password-protected, however, so be sure to delete any extraneous copies after you've got it in place.
Now we need to create a client certificate signing request. The OpenSSL command to do this is similar to that used to create server certificates:
$ openssl req -new -keyout client_key.pem \
-out client_req.pem -days 730 -config ./openssl.cnf
As you can see, we're writing our signing request and key to the files client_req.pem and client_key, respectively. Unlike with the server signing requests, however, we're omitting the -nodes option. Therefore, when you run this command, you are prompted for a passphrase with which the certificate's private key can be encrypted.
Enter PEM pass phrase: devil1
Next we sign the client certificate's signing request:
$ openssl ca -config ./openssl.cnf \
-policy policy_anything -out client_cert.pem \
-extensions xpclient_ext -extfile ./xpextensions \
-infiles ./client_req.pem
(challenge password : telematique1)
Again, this is similar to the equivalent command for our server, except this time the -extensions command references a different entry in xpextensions. Also, if your clients run Linux, you should delete the extraneous stuff in the certificate, like you did with server_cert.pem. You then either can leave the certificate and key files separate or concatenate them. From there, copy your client certificate file(s) to your Linux client system.
If your certificate is to be used by a Windows XP client, you have one more step to take. You need to convert the certificate file(s) to a PKCS12-format file, with this command:
$ openssl pkcs12 -export -in client_cert.pem \
-inkey client_key.pem -out client_cert.p12 -clcerts
(enter passphrase for ./jhCA/private/cakey.pem devil1)
You are prompted for client_key.pem's passphrase and then for a new passphrase for the new file; you can use the same password as before if you like. You may be tempted simply to press Enter instead, especially given that the WPA supplicant in Windows XP works only when you store its certificates without passphrases. It could be dangerous to move private keys around networks unprotected, so It would be good practice if you remove the passphrase after this file is copied safely over to your Windows XP client.
The resulting file, in this example client_cert.p12, contains both your signed certificate and its private key. Copy it to your Windows XP client system.
So we have generated server and client certificates and transferred them to their respective hosts. Now we need to configure FreeRADIUS, our access point and our wireless clients.
The tasks at hand are:
To install the server and CA certificates we created last time onto our FreeRADIUS server.
To configure FreeRADIUS to use these certificates with EAP-TLS to authenticate users for our access point.
To configure our access point to redirect authentication to our FreeRADIUS server.
To install the client and CA certificates we created last time onto a Windows XP client and configure it to use WPA when connecting to the WLAN.
Configuring the freeradius server
We created three X.509 digital certificates: a certificate authority certificate, called cacert.pem; one server certificate, called server_keycert.pem; and a client certificate, called client_cert.p12. The server and client files contain both a certificate and its private key, so each of these must be handled carefully. The CA certificate, however, is stored separately from its key, so you can distribute cacert.pem freely.
FreeRADIUS stores its configuration files in /etc/freeradius/ in Debian lenny. This directory contains a subdirectory, certs/—this, naturally, is where you need to copy your CA certificate and your server certificate/key. Make sure that cacert.pem is owned by the user root and that its permissions are set to -r--r--r--.
server_keycert.pem, on the other hand, should be owned by the user freerad and its permissions set to -r--------.
cp /etc/ssl/jhCA/cacert.pem /etc/freeradius/certs/cacert.pem
cp /etc/ssl/server_keycert.pem /etc/freeradius/certs/server_keycert.pem
Hereafter, the listing shows the long directory listings for these two files.
-r--r--r-- 1 root freerad 1294 2009-02-10 01:05 cacert.pem
-r-------- 1 freerad freerad 1894 2009-02-10 01:00 server_keycert.pem
You also should make sure that the file /var/log/freeradius/radius.log and the directory /var/run/freeradius/ are writable by freerad. Both radius.log and freeradius/ may be owned by freerad.
Before we edit freeradius' configuration files, we need to create two files that freeradius must have in order to use TLS. The first is a Diffie-Hellman parameters file, or dh file, which is used for negotiating TLS session keys. To create a dh file, change your working directory to /etc/freeradius/certs/ directory and issue this command:
# openssl dhparam -check -text -5 512 -out dh
The second file you need is a data file that contains a random bitstream that also is used in TLS operations. From within certs, run this command:
# dd if=/dev/urandom of=random count=2
Both of these files need to be readable by the user freerad, but they should not be writable by anybody.
# chown freerad dh
# chmod o-w dh
We're finally ready to configure freeradius. You may be afraid when you see the long list of files in /etc/freeradius, but don't be. For WPA with EAP-TLS, we need to edit only three files: radiusd.conf, eap.conf and clients.conf.
In radiusd.conf, all we need to do is verify the user and group accounts that the radiusd process runs as. By default these are inherited from whatever user starts the dæmon. If you run radiusd from a startup script, this is root; however, you definitely do not want to run radiusd as root. Therefore, you should set the user and group parameters in radiusd.conf, both set to freerad, as shown below.
Two Parameters to verify in radiusd.conf
user = freerad
group = freerad
Naturally you can choose different nonprivileged user and group accounts instead of freerad and freerad, but if you do so, you need to adjust the ownerships and permissions on the certificate files we created earlier. Regardless, make sure your nonprivileged user's entry in /etc/password sets the user's shell to a non-shell, such as /bin/false or /bin/true—this account should not be usable for SSH, telnet or similar programs. For that matter, make sure both the user and group accounts exist in the first place, and create them if they don't.
Other parameters may be set in radiusd.conf, but these really are the most important parameters we have to check.
The next file we need to edit is eap.conf; here's where the real heavy lifting occurs. Listing below shows the lines you need to edit in eap.conf.
Changes in eap.conf
eap {
# There are several generic EAP parameters you can
# set here, but the important one for our purposes
# is default_eap_type:
default_eap_type = tls
# Next come parameters for specific EAP types. Since
# we're going to use EAP-TLS, the tls{} section is
# the one we care about:
tls {
#
# These is used to simplify later configurations.
#
certdir = ${confdir}/certs
cadir = ${confdir}/certs
private_key_password = whatever
private_key_file = ${certdir}/server_keycert.pem
# If Private key & Certificate are located in
# the same file, then private_key_file &
# certificate_file must contain the same file
# name.
#
# If CA_file (below) is not used, then the
# certificate_file below MUST include not
# only the server certificate, but ALSO all
# of the CA certificates used to sign the
# server certificate.
certificate_file = ${certdir}/server_keycert.pem
# Trusted Root CA list
#
# ALL of the CA's in this list will be trusted
# to issue client certificates for authentication.
#
# In general, you should use self-signed
# certificates for 802.1x (EAP) authentication.
# In that case, this CA file should contain
# *one* CA certificate.
#
# This parameter is used only for EAP-TLS,
# when you issue client certificates. If you do
# not use client certificates, and you do not want
# to permit EAP-TLS authentication, then delete
# this configuration item.
CA_file = ${cadir}/cacert.pem
#
# For DH cipher suites to work, you have to
# run OpenSSL to create the DH file first:
#
# openssl dhparam -out certs/dh 1024
#
dh_file = ${certdir}/dh
random_file = ${certdir}/random
#
# This can never exceed the size of a RADIUS
# packet (4096 bytes), and is preferably half
# that, to accomodate other attributes in
# RADIUS packet. On most APs the MAX packet
# length is configured between 1500 - 1600
# In these cases, fragment size should be
# 1024 or less.
#
fragment_size = 1024
# include_length is a flag which is
# by default set to yes If set to
# yes, Total Length of the message is
# included in EVERY packet we send.
# If set to no, Total Length of the
# message is included ONLY in the
# First packet of a fragment series.
#
include_length = yes
# Check the Certificate Revocation List
#
# 1) Copy CA certificates and CRLs to same directory.
# 2) Execute 'c_rehash
# 'c_rehash' is OpenSSL's command.
# 3) uncomment the line below.
# 5) Restart radiusd
# check_crl = yes
# CA_path = /path/to/directory/with/ca_certs/and/crls/
#
# If check_cert_issuer is set, the value will
# be checked against the DN of the issuer in
# the client certificate. If the values do not
# match, the cerficate verification will fail,
# rejecting the user.
#
# check_cert_issuer = "/C=GB/ST=Berkshire/L=Newbury/O=My Company Ltd"
#
# If check_cert_cn is set, the value will
# be xlat'ed and checked against the CN
# in the client certificate. If the values
# do not match, the certificate verification
# will fail rejecting the user.
#
# This check is done only if the previous
# "check_cert_issuer" is not set, or if
# the check succeeds.
#
check_cert_cn = %{User-Name}
#
# Set this option to specify the allowed
# TLS cipher suites. The format is listed
# in "man 1 ciphers".
cipher_list = "DEFAULT"
#
# This configuration entry should be deleted
# once the server is running in a normal
# configuration. It is here ONLY to make
# initial deployments easier
# make_cert_command = "${certdir}/bootstrap"
}
}
We have specified a server-key passphrase with the private_key_password parameter. This actually should be empty if you created your server certificate and key with OpenSSL's -nodes option.
Make sure that eap.conf is owned and readable only by root . This may seem paradoxical doesn't freerad need to be able to read configuration files? But, if you start the freeradius daemon as root, it reads its configuration files, including radiusd.conf, eap.conf and clients.conf, before demoting itself to freerad.
Finally, you need to create an entry for your access point in clients.conf. The listing below shows such an entry for a 3com 7760 a/b/g Access Point (default IP address is 169.254.2.2 when no DHCP server is answering its request).
Access Point Entry in clients.conf
client 169.254.2.2/32 {
secret = testing123
shortname = liv1
}
The client statement specifies the access point's IP address. Its secret parameter specifies a string that your access point uses as an encryption key for all queries it sends to your FreeRADIUS server. shortname simply is an alias for your access point to be used in log entries and so on.
You now can (re)start freeradius by using the rc.radiusd script, for e0xample, rc.radiusd start or by typing freeradius -X -f.
Configuring the Access Point
The next step is the easiest part of this entire process: configure your wireless access point to use WPA and to point to your FreeRADIUS server. This requires only two pieces of information, the RADIUS secret you entered in your FreeRADIUS server's clients.conf file and the IP address of your FreeRADIUS server.
How you present those two pieces of information to your access point depends on your particular hardware and software. The access point used in this howto is a 3com 7760 configuring it via http is a piece of cake.
If your access point and RADIUS server are separated by a firewall, you need to allow the access point to reach the RADIUS server on UDP ports 1812 and 1813. Doing so also allows the RADIUS server to send packets back from those ports.
Configuring Windows XP Clients
Configuring a Windows XP wireless client to use your WPA-enabled access point.
In summary, you need to:
Run the command mmc from Start→Run....
In Microsoft Management Console, select File→Add/Remove Snap-in, add the Certificates snap-in and set it to manage certificates for My user account and, on the next screen, only for the Local computer.
Copy your CA (cacert.pem) certificate to your Windows system's hard drive, for example, to C:\cacert.pem.
From within MMC, expand Console Root and Certificates - Current User and right-click on Trusted Root Certification Authorities. In the pop-up menu, select All Tasks→Import. Tell the subsequent wizard to import the file C:\cacert.pem and to store it in Trusted Root Certification Authorities.
Copy your client certificate/key file to your Windows system, for example, to C:\client_cert.p12.
From within MMC→Console Root→Certificates, expand Personal and right-click on Certificates. In the pop-up menu, select All Tasks→Import. Tell the subsequent wizard to import the file C:\client_cert.p12.
The certificate-import wizard then prompts you for the certificate's passphrase. In the same dialog, it offers the option to enable strong private key protection. Unfortunately, enabling this breaks WPA, so be sure to leave this option unchecked. Also, leave the option to mark this key as exportable unchecked—you're better off backing up the password-protected file you just imported rather than allowing the imported nonprotected version to be exportable.
In the subsequent screen, let the wizard Automatically select the certificate store.
Now your Windows XP system is ready to go—all that remains is to create a wireless network profile. This, however, varies depending on your wireless card's drivers and which Windows XP Service Pack you're running. According to my little experience on using WPA entreprise on Windows XP, SP2 is a minimal requisite if you want a quite functional and stable connection. I set Network Authentication to WPA, Data encryption to TKIP and EAP type to Smart Card or other Certificate. Windows automatically determined which client certificate I used—this is because we took pains to create a client certificate that references Windows XP's extended attributes
.
After you configure your wireless network profile, your Windows system should connect automatically to your access point and negotiate a WPA connection. If this succeeds, Network Connections should show a status of Authentication succeeded for your Wireless Network Connection entry.
26 février 2009
Freeradius avec EAP-TLS/TTLS/PEAP
Debian's FreeRadius package is built without support for EAP/TLS/TTLS/PEAP because of the licensing problems of the OpenSSL library. But, if you want to implement 802.1x network authentication with strong security, you'll need it. This is a short tutorial that explains how to build Debian (sid aka unstable) package linked to libssl and with EAP/TLS/TTLS/PEAP support compiled in.
I suppose you work with lenny (minimal installation + apt-get install x-window-system-core + apt-get install gnome-core synaptic)
First apt-get install dpkg-dev fakeroot
Download the newest source package (orig.tar.gz), Debian diffs (diff.gz) and description file (dsc) from the freeradius package page. The version I tested the procedure with is freeradius-2.0.4+dfsg$
Unpack the source and switch to the resulting directory like this:
% dpkg-source -x *.dsc
dpkg-source: extracting freeradius in freeradius-2.0.4+dfsg$
dpkg-source: unpacking freeradius_2.0.4+dfsg-6.diff.gz
dpkg-source: applying ./freeradius_2.0.4+dfsg-6.diff.gz
% cd freeradius-*
There are four changes that must be done in order to successfully build the package:
1. edit debian/rules, search for eap and change every mentioning of --without-rlm_eap-* to --with-rlm_eap-* excepted --without-rlm_eap_ikev2, --without-rlm_eap_tnc --without-rlm_sql_oracle --without-rlm_sql_unixodbc
2. few lines below, in the same file, replace --without-openssl with --with-openssl
3. still editing the same file, find the following chuck of code and comment it entirely:
for pkg in ${pkgs} ; do \
if dh_shlibdeps -p $$pkg -- -O 2>/dev/null | grep -q libssl; then \
echo "$$pkg links to openssl" ;\
exit 1 ;\
fi ;\
done
4. finally, edit debian/control and at the end of the line starting with Build-Depends: (second line in the file) add , libssl-dev
Finally, I needed to install piles of packages before running "dpkg-buildpackage -rfakeroot":
# apt-get install libssl-dev debhelper libgdbm-dev libiodbc2-dev libkrb5-dev libldap2-dev libltdl3-dev libmysqlclient15-dev libpam0g-dev libpcap-dev libperl-dev libpq-dev libsasl2-dev libsnmp-dev python-dev
That should do it, you can now build package like this:
% dpkg-buildpackage -rfakeroot
You're doing all the above steps as a normal user, and if everything goes well, you'll find 10 debian packages in the parent directory which you can now install. Don't forget to hold newly installed packages in your package manager so that you don't experience breakage when you pull upgrades next time, and new official versions (without EAP/TLS/TTLS/PEAP support) overwrite your custom built packages.
To hold the packages, as suggested after step 4, I used the command:
# aptitude hold freeradius-common freeradius freeradius-dbg freeradius-iodbc freeradius-krb5 freeradius-ldap freeradius-mysql freeradius-postgresql freeradius-utils libfreeradius-dev libfreeradius2
Then you can see that they are in the "hold" state when you use aptitude. Although for some reason they appear in the "install" state when you use:
# dpkg --get-selections freer*
Probably why they say you shouldn't mix and match dpkg and apt.
More info about package management here:
http://www.debian.org/doc/FAQ/ch-pkg_basics.en.html
Installation:
-------------
hp-debian-stable:/home/hanoteau# dpkg --install freeradius-common_2.0.4+dfsg-6_all.deb
Sélection du paquet freeradius-common précédemment désélectionné.
(Lecture de la base de données... 99926 fichiers et répertoires déjà installés.)
Dépaquetage de freeradius-common (à partir de freeradius-common_2.0.4+dfsg-6_all.deb) ...
Paramétrage de freeradius-common (2.0.4+dfsg-6) ...
Ajout de l'utilisateur freerad au groupe shadow
Traitement des actions différées (« triggers ») pour « man-db »...
hp-debian-stable:/home/hanoteau# dpkg --install libfreeradius2_2.0.4+dfsg-6_i386.deb
Sélection du paquet libfreeradius2 précédemment désélectionné.
(Lecture de la base de données... 100311 fichiers et répertoires déjà installés.)
Dépaquetage de libfreeradius2 (à partir de libfreeradius2_2.0.4+dfsg-6_i386.deb) ...
Paramétrage de libfreeradius2 (2.0.4+dfsg-6) ...
hp-debian-stable:/home/hanoteau# dpkg --install freeradius_2.0.4+dfsg-6_i386.deb
(Lecture de la base de données... 100317 fichiers et répertoires déjà installés.)
Préparation du remplacement de freeradius 2.0.4+dfsg-6 (en utilisant freeradius_2.0.4+dfsg-6_i386.deb) ...
Dépaquetage de la mise à jour de freeradius ...
Paramétrage de freeradius (2.0.4+dfsg-6) ...
suppression du / final
suppression du / final
suppression du / final
Starting FreeRADIUS daemon: freeradius.
I suppose you work with lenny (minimal installation + apt-get install x-window-system-core + apt-get install gnome-core synaptic)
First apt-get install dpkg-dev fakeroot
Download the newest source package (orig.tar.gz), Debian diffs (diff.gz) and description file (dsc) from the freeradius package page. The version I tested the procedure with is freeradius-2.0.4+dfsg$
Unpack the source and switch to the resulting directory like this:
% dpkg-source -x *.dsc
dpkg-source: extracting freeradius in freeradius-2.0.4+dfsg$
dpkg-source: unpacking freeradius_2.0.4+dfsg-6.diff.gz
dpkg-source: applying ./freeradius_2.0.4+dfsg-6.diff.gz
% cd freeradius-*
There are four changes that must be done in order to successfully build the package:
1. edit debian/rules, search for eap and change every mentioning of --without-rlm_eap-* to --with-rlm_eap-* excepted --without-rlm_eap_ikev2, --without-rlm_eap_tnc --without-rlm_sql_oracle --without-rlm_sql_unixodbc
2. few lines below, in the same file, replace --without-openssl with --with-openssl
3. still editing the same file, find the following chuck of code and comment it entirely:
for pkg in ${pkgs} ; do \
if dh_shlibdeps -p $$pkg -- -O 2>/dev/null | grep -q libssl; then \
echo "$$pkg links to openssl" ;\
exit 1 ;\
fi ;\
done
4. finally, edit debian/control and at the end of the line starting with Build-Depends: (second line in the file) add , libssl-dev
Finally, I needed to install piles of packages before running "dpkg-buildpackage -rfakeroot":
# apt-get install libssl-dev debhelper libgdbm-dev libiodbc2-dev libkrb5-dev libldap2-dev libltdl3-dev libmysqlclient15-dev libpam0g-dev libpcap-dev libperl-dev libpq-dev libsasl2-dev libsnmp-dev python-dev
That should do it, you can now build package like this:
% dpkg-buildpackage -rfakeroot
You're doing all the above steps as a normal user, and if everything goes well, you'll find 10 debian packages in the parent directory which you can now install. Don't forget to hold newly installed packages in your package manager so that you don't experience breakage when you pull upgrades next time, and new official versions (without EAP/TLS/TTLS/PEAP support) overwrite your custom built packages.
To hold the packages, as suggested after step 4, I used the command:
# aptitude hold freeradius-common freeradius freeradius-dbg freeradius-iodbc freeradius-krb5 freeradius-ldap freeradius-mysql freeradius-postgresql freeradius-utils libfreeradius-dev libfreeradius2
Then you can see that they are in the "hold" state when you use aptitude. Although for some reason they appear in the "install" state when you use:
# dpkg --get-selections freer*
Probably why they say you shouldn't mix and match dpkg and apt.
More info about package management here:
http://www.debian.org/doc/FAQ/ch-pkg_basics.en.html
Installation:
-------------
hp-debian-stable:/home/hanoteau# dpkg --install freeradius-common_2.0.4+dfsg-6_all.deb
Sélection du paquet freeradius-common précédemment désélectionné.
(Lecture de la base de données... 99926 fichiers et répertoires déjà installés.)
Dépaquetage de freeradius-common (à partir de freeradius-common_2.0.4+dfsg-6_all.deb) ...
Paramétrage de freeradius-common (2.0.4+dfsg-6) ...
Ajout de l'utilisateur freerad au groupe shadow
Traitement des actions différées (« triggers ») pour « man-db »...
hp-debian-stable:/home/hanoteau# dpkg --install libfreeradius2_2.0.4+dfsg-6_i386.deb
Sélection du paquet libfreeradius2 précédemment désélectionné.
(Lecture de la base de données... 100311 fichiers et répertoires déjà installés.)
Dépaquetage de libfreeradius2 (à partir de libfreeradius2_2.0.4+dfsg-6_i386.deb) ...
Paramétrage de libfreeradius2 (2.0.4+dfsg-6) ...
hp-debian-stable:/home/hanoteau# dpkg --install freeradius_2.0.4+dfsg-6_i386.deb
(Lecture de la base de données... 100317 fichiers et répertoires déjà installés.)
Préparation du remplacement de freeradius 2.0.4+dfsg-6 (en utilisant freeradius_2.0.4+dfsg-6_i386.deb) ...
Dépaquetage de la mise à jour de freeradius ...
Paramétrage de freeradius (2.0.4+dfsg-6) ...
suppression du / final
suppression du / final
suppression du / final
Starting FreeRADIUS daemon: freeradius.
24 février 2009
23 février 2009
Ubuntu 8.10 ati drivers images saccadées pour reproduction video
Tu dois désactiver l'accélération vidéo de ton serveur X en changeant le module de sortie vidéo qui est utilisé par tes logiciels de réproduction vidéo.
Pour utiliser totem et tous les logiciels utilisant le gstreamer backend, ouvre le terminal et exécute ce command:
gstreamer-properties
Ensuite clique sur l'onglet "Video" et sous Défaut Sortie sélectionne "X Window System (pas d' Xv)" pour le plugin.
Redémarre Totem.
Pour utiliser VLC sélectionne Configurations > Préférénces , puis à droite au bas de la fenetre marque "Options Avancèes". Apres ça enlarge la sectionne Vidéo à gauche et selectionne "Modules de Sortie". Ensuite modifie le module qui se trouve à droite dans la liste "module de sortie vidéo" en "Sortie vidéo X11"
Rédemarre VLC.
Pour utiliser totem et tous les logiciels utilisant le gstreamer backend, ouvre le terminal et exécute ce command:
gstreamer-properties
Ensuite clique sur l'onglet "Video" et sous Défaut Sortie sélectionne "X Window System (pas d' Xv)" pour le plugin.
Redémarre Totem.
Pour utiliser VLC sélectionne Configurations > Préférénces , puis à droite au bas de la fenetre marque "Options Avancèes". Apres ça enlarge la sectionne Vidéo à gauche et selectionne "Modules de Sortie". Ensuite modifie le module qui se trouve à droite dans la liste "module de sortie vidéo" en "Sortie vidéo X11"
Rédemarre VLC.
GScrot change de nom
et devient shutter
dès lors il faut changer la source de dépôt (p. ex. ubuntu 8.10):
deb http://ppa.launchpad.net/shutter/ppa/ubuntu intrepid main
dès lors il faut changer la source de dépôt (p. ex. ubuntu 8.10):
deb http://ppa.launchpad.net/shutter/ppa/ubuntu intrepid main
12 février 2009
Script erreur d'encodage dos
bash: ./bootstrap: /bin/sh^M: bad interpreter: Aucun fichier ou répertoire de ce type
Tu as le ^M typique du fichier DOS sous Unix.
Utilise la commande dos2unix pour avoir un fichier Unix ( a cause de \n qui n'est pas code de la meme facon sous DOS et UNIX
apt-get install tofrodos
unix2dos file.txt
Tu as le ^M typique du fichier DOS sous Unix.
Utilise la commande dos2unix pour avoir un fichier Unix ( a cause de \n qui n'est pas code de la meme facon sous DOS et UNIX
apt-get install tofrodos
unix2dos file.txt
04 février 2009
Erreur de droits sur $HOME/.dmrc (ubuntu 8.10)
erreur:
your $home/.dmrc has incorrect permissions and is being ignored. This prevents the default session and language from beeing saved. File should be owned by user and have 644 permission
solution:
chmod 644 ~/.dmrc
sudo chown votre_login /home/votre_login/.dmrc
chmod 700 /home/votre_login
your $home/.dmrc has incorrect permissions and is being ignored. This prevents the default session and language from beeing saved. File should be owned by user and have 644 permission
solution:
chmod 644 ~/.dmrc
sudo chown votre_login /home/votre_login/.dmrc
chmod 700 /home/votre_login
Clés ppa liste des sources ubuntu
PROBLEME:
sudo apt-get update
W: GPG error: http://ppa.launchpad.net hardy Release: Les signatures suivantes n'ont pas pu être vérifiées car la clé publique n'est pas disponible : NO_PUBKEY 632D16BB0C713DA6
SOLUTION:
gpg --keyserver hkp://keyserver.ubuntu.com:11371 --recv-key 632D16BB0C713DA6
gpg -a --export 632D16BB0C713DA6 | sudo apt-key add -
sudo apt-get update
sudo apt-get update
W: GPG error: http://ppa.launchpad.net hardy Release: Les signatures suivantes n'ont pas pu être vérifiées car la clé publique n'est pas disponible : NO_PUBKEY 632D16BB0C713DA6
SOLUTION:
gpg --keyserver hkp://keyserver.ubuntu.com:11371 --recv-key 632D16BB0C713DA6
gpg -a --export 632D16BB0C713DA6 | sudo apt-key add -
sudo apt-get update
03 février 2009
13 janvier 2009
comment ajouter des "shapes" dans les menus (feuilles) de dia
Voir cet excellent lien: http://dia-installer.de/howto/create_shape/
08 janvier 2009
liste des paquets installés ubuntu
La solution est pourtant assez simple, il suffit de penser à se servir de dpkg :
D’abord, on génére la liste des paquets installés sur le poste original :
$~ dpkg --get-selections > /tmp/liste_paquets.txt
Ensuite on copie la liste de paquets sur la machine cible
Et on finit par installer tous les paquets de la liste avec une simple ligne :
$~ dpkg --set-selections < /tmp/liste_paquets.txt
$~ dselect
Encore une fois, ce n’est pas une astuce très élaborée, mais elle m’a permit d’aller beaucoup plus vite avec mes installations…
D’abord, on génére la liste des paquets installés sur le poste original :
$~ dpkg --get-selections > /tmp/liste_paquets.txt
Ensuite on copie la liste de paquets sur la machine cible
Et on finit par installer tous les paquets de la liste avec une simple ligne :
$~ dpkg --set-selections < /tmp/liste_paquets.txt
$~ dselect
Encore une fois, ce n’est pas une astuce très élaborée, mais elle m’a permit d’aller beaucoup plus vite avec mes installations…
05 janvier 2009
Sauvegarde de DVDs
Lancez vobcopy. Il copiera automatiquement tous les VOBS qui correspondent au titre contenant le plus de chapitres sur votre disque dur.
* Tout d'abord, montez votre DVD si c'est encore nécessaire sur votre distribution: mount /media/cdrom0 (par exemple pour mon lecteur dvd graveur de cds)
* Copiez les VOBs avec vobcopy: vobcopy -i /media/cdrom0 -m
Ceci copiera les VOBs du DVD et les écrira dans le répertoire courant (que vous pouvez modifier avec, par exemple, -o /space). Ils seront nommés selon le titre du DVD (par exemple, j'ai ALLY_MCBEAL_DISC21-1.vob, ALLY_MCBEAL_DISC21-2.vob etc.). L'option -m demande à vobcopy de créer un miroir du contenu du DVD, en incluant les fichiers .IFO - utiles car vous pouvez alors utiliser la copie locale avec MPlayer/MEncoder ou transcode comme si c'était le vrai DVD. Cela prendra du temps. Soyez patient.
Inspiré de http://www.bunkus.org/dvdripping4linux/fr/separate/ripping.html
* Tout d'abord, montez votre DVD si c'est encore nécessaire sur votre distribution: mount /media/cdrom0 (par exemple pour mon lecteur dvd graveur de cds)
* Copiez les VOBs avec vobcopy: vobcopy -i /media/cdrom0 -m
Ceci copiera les VOBs du DVD et les écrira dans le répertoire courant (que vous pouvez modifier avec, par exemple, -o /space). Ils seront nommés selon le titre du DVD (par exemple, j'ai ALLY_MCBEAL_DISC21-1.vob, ALLY_MCBEAL_DISC21-2.vob etc.). L'option -m demande à vobcopy de créer un miroir du contenu du DVD, en incluant les fichiers .IFO - utiles car vous pouvez alors utiliser la copie locale avec MPlayer/MEncoder ou transcode comme si c'était le vrai DVD. Cela prendra du temps. Soyez patient.
Inspiré de http://www.bunkus.org/dvdripping4linux/fr/separate/ripping.html
Inscription à :
Articles (Atom)