L’utilisation de GIT peut être assez déroutante au premier abord, notamment pour les habitués à SVN, mais on devient très vite accro à la gestion des branches de GIT , qui permet d’organiser correctement son propre code, celui d’une équipe et de suivre l’évolution du projet. GIT possède son propre vocabulaire, j’espère vous éclairer un peu avec ces premiers pas. Pour tous les détails, consultez les livres online : Pro Git et GIT community Book.

Quelques avantages de git :

• Souplesse dans la gestion des branches
• Décentralisé
• Pas de serveur, un accès SSH suffit
• Un seul dossier .git à la racine du projet
• Le développeur peut créer ses propres branches locales
• Espace disque et transferts réseau très limités

A contrario de SVN, les branches sont stockées dans le même répertoire de travail, et vous switchez de l’une à l’autre grâce la commande ‘git checkout’. cette commande remplace/supprimer et déplace les fichiers à la demande. Pour pouvoir changer de branche, tous les changements doivent être commités.

Dans un cas classique, plusieurs développeurs vont travailler sur le même projet, chacun sur sa branche, et l’un d’eux (le ‘dictator’) sera chargé de réintégrer toutes les modifs dans le ‘master’ (via des ‘merge’). Une fois ces modifs publiées, chaque développeur pourra alors les réintégrer dans son propre code. Ce workflow est un exemple de base, de nombreux cas plus évolués sont possibles.

Si vous avez besoin de centraliser votre repository, vous pouvez utiliser un simple serveur avec accès SSH pour vos users, ou GitHub.com qui offre des repos gratuits pour les projets open source et 12$/mois pour 5 repos privés si besoin. L’avantage de cette dernière solution est sa facilité de mise en oeuvre ainsi que l’accès à l’excellente interface web de GitHub qui permet de consulter le code, les commits, d’avoir des stats, un systeme de wiki, but tracker… De plus, GitHub propose une fonction de Click&Fork qui permet de forker nimporte quel projet en un clic. La mise à jour du code peut ensuite se faire dans les deux sens… ce qui est parfait pour le modèle open source.

Une fois l’installation de git effectuée, récupérez un projet :

pour un projet hébérgé sur un serveur SSH :

pour un projet hébérgé sur GitHub :

Dans les deux cas,  cela crée un dossier KillerApp.git avec le projet et la branche ‘master’ uniquement.

Si vous voulez rappatrier d’autres branches du serveur distant (origin), il faut les ajouter manuellement ;

Ceci crée les branches locales, qui sont ‘linkées’ à leurs branches remotes respectives

On va passer dans la branche ‘juju’

l’étoile indique qu’on travaille dans la branche ‘juju’

Pour créer une nouvelle branche locale ‘newfeature’ depuis la branche actuelle et se déplacer dedans :

Attention, la branche est issue par defaut de la branche en cours, et pas du ‘master’

Pour changer de branche :

Pour repasser dans la branche newfeature :

Une fois dans votre branche de dev, faites des git commit dès que nécessaire. Les fichiers modifies/ajoutes doivent etre ajoutés a l’index GIT via :

ou, pour ajouter automatiquement tous les fichiers :

Il faut savoir que GIT est complètement décentralisé et que les branches locales/remote ne sont pas forcement synchronisées (’trackées’). Dans notre exemple, la branche ‘newfeature’ n’existe qu’en local et ne pourra pas etre ‘pushée’ sur le remote, sauf si on spécifie manuellement un lien vers un repo distant.

Une fois la ‘newfeature’ codée, le développeur doit la réintégrer dans sa branche;  il doit bien sur d’abord commit son code, puis faire un merge :

Il passe d’abord dans sa branche :

Puis merge le code de sa ‘newfeature’

Maintenant, la branche juju contient le code de newfeature et il a été commit automatiquement (en local).

Envoi de notre nouveau code sur le repository distant

Envoyer sur la branche ‘juju’

Il peut envoyer son code sur le remote (cela pushera la branche juju vers la branche remote ‘juju’) :

Un responsable se chargera alors de merger la branche juju dans la branche master et de mettre a jour le master sur le repo central.

Envoyer sur la branche ‘master’ directement

Éventuellement, le développeur peut intégrer ses modifs directement dans la branche ‘master’ :

Il passe sur la branch master :

Il récupère déjà le code du master actuel :

Puis merge sa branche dedans :

Puis envoi sur le remote :

Récupération de code sur le repository distant

Si le developpeur veut réintégrer dans sa branche les mises à jour de ses collègues :

récupérer toutes les branches distantes configurées :

merger le code du master dans la branch actuelle

La branche ‘juju’ est alors mise à jour avec le nouveau code issu de ‘master’ (le trunk)

Quelques commandes utiles :

• Lister les branches sur le repo distant :

• Créer une nouvelle branche ‘daniel’  locale, la créer aussi sur le remote, et la tracker : (double – before ‘track’)

• Sauvegarder en mémoire les modifs depuis le dernier checkout pour les réappliquer dans une autre branche. Attention, ‘git stash’ reset votre branch au dernier commit (HEAD) :

• Créer un nouveau repository local vide : (double – before ‘bare’)

• Express local commit :

• Afficher un diff des modifications

• Afficher un logdes commits

Tips :

• Créez un fichier .gitignore pour ignorer des fichiers/dossiers (ce fichier peut etre different par branche)
• Utilisez ce script dans votre .bashrc pour afficher la branche dans votre prompt
• Consultez stackoverflow.com il y a pleins d’idées intéressantes
• SVN GIT Crach course : http://git.or.cz/course/svn.html
• GIT magic
• Exemple de workflow, avec des graphiques instructifs

Voici une procédure simplifiée que j’ai suivie sur une debian avec un kernel dedibox r5 :

* apt-get update && apt-get upgrade : mettre a jour les packages pour le nouveau noyau. Attention, cette étape peut vous forcer à passer à MySQL5 et PHP5

* installation du nouveau kernel : apt-get install linux-image-2.6.18-6-686

* reboot puis uname -r pour voir si tout va bien : Linux xx_xx 2.6.18-6-686

Si votre machine ne redemarre pas, essayez un reboot materiel via la console et au pire, bootez sur le system de secours pour modifier /boot/grub/menu.lst et remettre votre ancien noyau (parametre ‘default’).

Ce patch est indispensable sinon tot ou tard votre systeme sera compromis.

Pour ceux qui souhaiterait installer leur propre kernel et le patcher, suivez le tuto de drax sur son (excellent) blog : vmsplice-exploit-fix-and-patching-on-debian et pour les plus curieux, plus de détails techniques sur cette faille : http://www.isec.pl/vulnerabilities/isec-0026-vmsplice_to_kernel.txt

Yuck. What’s more, if you’re using SuExec (like I am) then your Apache directives are ignored.

Solution: Edit your trac.fcgi and prepend the following code.

# hack for SuExec
import os;
os.environ['TRAC_ENV_PARENT_DIR'] = '/var/lib/trac'

Affected versions: >= 2.6.17
Fixed in version: 2.6.24.2

Fix

You can download the vmsplice patch locally or from the official LKML thread: [PATCH] vmsplice exploit fix

Patching on Debian Etch

Update 12/02/08: Debian repositories have been updated and contain patched kernels. If you’re using a stock kernel, the following two commands should sort you out (providing you reboot afterwards).

aptitude update
aptitude upgrade

Install kernel sources

export KVER=`uname -r`
aptitude update
aptitude install linux-source-${KVER}
cd /usr/src
tar -xjf linux-source-${KVER}.tar.bz2
ln -s linux-source-${KVER} linux
cd linux

Patch kernel sources

patch < vmsplice.patch -p1

Compile kernel and install

You'll want to copy your existing kernel configuration.

cp /boot/config-${KVER} .config
make-kpkg clean
make-kpkg --initrd --append-to-version=-mykernelname kernel_image
cd ..
dpkg -i linux-image-${KVER}-mykernelname_${KVER}-mykernelname-10.00.Custom_i386.deb
reboot

References

• http://www.isec.pl/vulnerabilities/isec-0026-vmsplice_to_kernel.txt
• http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=465246
• http://milw0rm.com/exploits/5092
• http://milw0rm.com/exploits/5093

TrueCrypt, probably the best solution available, was only working on Linux and Windows… up to now.

Some dude got impatient for the OS X port, managed to make a deal with a developper to code it for 1500$, raised those 1500$ and BAM! Bob’s you’re uncle.

The software is labelled alpha, described as beta, and used in production… w00t. Jokes aside, it’s been released for a few weeks now and no serious data-destroying bug stories have arose. Nevertheless, you might want to backup to another more trusted encrypted disk somewhere, every now and then.

Bare in mind the TrueCrypt team annouce their 5.0 release for the 4th of Febuary 2008 (that’s in 2 days) and claim OS X support. Watch this space…

Still interested? Download the software here:

• TrueCrypt for OS X
• TrueCrypt for Linux and Windows

OS X notes:

• Your encrypted filesystem image should have a .img extension.
• When mounting a hidden volume, you’ll be asked the outer volume password, then the hidden volume password.
• Unmounting in finder does not dismount the image. It’s a known bug. Use ocutil -detach.

Au premier abord l’eee pc est vraiment petit, normal me direz vous avec écran 7 pouces, 4Go de SSD, 900 grammes et 319€TTC. La webcam intégrée (et oui!) est de piètre qualité mais ca suffit pour de la visioconférence et des petites photos.

Au second abord, il est petit aussi, et c’est pour cela qu’on l’achete  La taille de l’écran, la resolution et les performances, ce n’est pas une machine pour coder ni pour travailler mais un petit pc de depannage pour surfer, se connecter à des shells, lire des videos et du son, communiquer… C’est deja pas mal.

 Le clavier, très petit, voir trop petit, demande un temps d’adaptation et le touchpad est très enervant car trop petit aussi. Il va falloir mettre une souris externe… peut etre celle ci !! En tous cas la batterie annonce 2h30 d’autonomie a plein régime ce qui est déjà respectable vu la taille de la batterie. 

La bête demarre en 30 secondes sur une distribution Xandros de ASUS, qui ressemble à première vue l’ordissimo de ma grand-mere; parfait pour les débutants mais si vous êtes geek, vous avez envie de configurer un vrai bureau avec vos petits widgets et tout ce qu’il faut.

J’ai donc d’abord tenté d’installer eeeXubuntu en suivant le tuto sur : http://wiki.eeeuser.com/ubuntu:eeexubuntu:home - malheureusement – il semblerait que la version de mes cartes WiFi et Internet ne soient pas intégrés dans cette version (7.10 r3) donc par manque de temps, de posts sur ce sujet, et de motiver a m’acharner sur ce minuscule clavier dépourvu de réseau, je suis finalement repassé sur Xandros, qui apres un peu de configuration ressemble beaucoup a une Ubuntu d’autant plus que c’est aussi basé sur Debian… Et la bien sur tout fonctionne bien dès le début…

Pour installer des programmes supplémentaire, ajoutez des dépots dans Synaptic depuis cette liste : http://wiki.eeeuser.com/addingxandrosrepos?s=repositories

L’EEE est un super portable d’appoint, sous linux, très accessible aux débutants, et disponible a moins de 300€ . Vu le succès apparemment rencontré par le produit (déjà en rupture de stocks dans plusieurs magasins), cela va permettre en tous cas de démocratiser Linux un peu plus et sensibiliser le public au logiciel libre.

NB : Vous pouvez acheter des cartes mémoires SDHC 4Go a moins de 20€ sur internet pour augmenter votre capacité de stockage.

HTTPS is just HTTP encapsulated inside an SSL tunnel. Apache’s virtual hosts are a clever “hack” whereby the Host header in the HTTP packet is verified. This alllows a single apache instance on a single IP/Port combination to serve a (not so) infinite number of differentes sites (aka vhosts).

Problem: The SSL tunnel is created before the first HTTP packet gets sent. Apache needs an SSL certificate but doesn’t have a Host header to match, hence cannot choose a virtual host.

Solution

This trick essentially does the matching of the Host header after the SSL connection has been established. How? Via some mod_rewrite magic!

Caveats

Although I said so, it’s not really that magical. There are a few things this trick does not solve.

• The SSL certificate used will be common to all SSL vhosts.
• Certain Apache directives may be common to all SSL vhosts (example: SuExecUserGroup). Basically anything you can’t override in a .htaccess file will be shared amongst vhosts.

The trick

The process is only 2 steps and involves modifying your Apache configuration. I assume you have a working SSL vhost configured.

1. Create virtual hosts “map file”.
2. Modify existing SSL vhost.

1. The virtual hosts map file

Create a new file in your Apache server root. Example:/etc/apache2/ssl.map

Write a list of virtual hosts and their respective DocumentRoot. Example:

foo.example.com        /var/www/foo.example.com/
bar.example.com        /var/www/bar.example.com/
# you can even put comments!
# Alias to bar
boar.example.com        /var/www/bar.example.com/

2. Edit your SSL vhost

Open your Apache config, inside the <VirtualHost> section of your SSL vhost, include the following code or include this file: Mass SSL vhosts Apache config.

Important: Make sure to edit line 8 to include the correct path to your ssl.map file.

### Mass SSL Vhosts ###
RewriteEngine on

#   define two maps: one for fixing the URL and one which defines
#   the available virtual hosts with their corresponding
#   DocumentRoot.
RewriteMap    lowercase    int:tolower
RewriteMap    vhost        txt:/etc/apache2/ssl.map

#   1. make sure we don't map for common locations
RewriteCond   %{REQUEST_URI}  !^/cgi-bin/.*
RewriteCond   %{REQUEST_URI}  !^/icons/.*

#   2. make sure we have a Host header
RewriteCond   %{HTTP_HOST}  !^$

#   3. lowercase the hostname
RewriteCond   ${lowercase:%{HTTP_HOST}|NONE}  ^(.+)$
#
#   4. lookup this hostname in vhost.map and
#      remember it only when it is a path
#      (and not "NONE" from above)
RewriteCond   ${vhost:%1}  ^(/.*)$

#   5. finally we can map the URL to its docroot location
#      and remember the virtual host for logging puposes
RewriteRule   ^/(.*)$   %1/$1  [E=VHOST:${lowercase:%{HTTP_HOST}}]

Restart Apache and you’re done. You should be able to browse (in https) the vhosts you added to your ssl.map file.

Grandma says: You don’t need to reload Apache when you edit your map file. Just create the document root folder on the filesystem, add a new entry to your map and you’re good to go.

J’ai décidé de migrer une de mes applis de Python/IIS vers mod_python/Apache2. C’est une appli encore assez simple, toujours en beta mais qui utilise toutes les fonctionnalités d’un serveur web : Environnement, Session, Cookies… De plus, je voulais n’utiliser que la librairie standard de mod_python; pas de modules complémentaires ni de frameworks web. A priori, tout cela est géré par mod_python (à partir de la v.3.1.3) donc : c’est parti !

La doc de mod_python etant assez limitée, je vais faire un petit résumé de ce que j’ai trouvé…

Déjà , il y a plusieurs facons d’utiliser mod_python : le mode standard, le mode Publisher, le mode PSP, ou encore le mode CGI.

ces 4 possibilités ont un impact au niveau des performances : cf comparatif perfs modpython. Et la facon de coder ne sera pas la même.

Le mode PSP permet de faire des pages .psp du style de pages PHP, avec le HTML et le code Python mixés. Pour des raisons de séparation du code et de la présentation, ce n’est pas l’idéal.

Le mode Publisher permet lui de faire quelque chose de plus pythonesque; on part d’un module python ou des fonctions répondront aux appels d’Apache, et on utilisera si besoin un système de templates HTML (classe PSP). Ce mode facilite aussi la vie du programmeur en automatisant certaines tâches (codes de retours Apache…)

J’ai opté pour la solution publisher car c’est la plus “Python Style”, la plus puissante en termes d’évolutivité, et elle est assez performante pour ce dont j’ai besoin.

Déjà , config dans Apache (je ne suis pas encore un pro de Apache) :

Exemple de .htaccess : on peut définir des variables auxquelles mod_python aura accès :

Exemples de page en Python :
Chaque fonction appellée par un navigateur se voit passer un argument ‘request’ (ici appellé req) qui permet d’accéder aux classes Request, Response, Session, Cookies…

Je post d’autres exemples très bientôt, stay tuned

A venir : Gestion session, cookie…

Le probleme est apparemment aussi présent sur Kubuntu!

Alors effacer ce fichier de log ou upgradez votre version, car le bug a été corrigé dans les mises à jour.

https://launchpad.net/distros/ubuntu/+source/shadow/+bug/34606

script pour tester la vulérabilité de votre système : http://www.ubuntuforums.org/showpost.php?p=818304&postcount=74

vulnérabilité dévcouverte par un noob

On y apprend comment installer et configurer le son si l’installation ne l’a pas pris en compte…

Bien utile, surtout pour les configs exotiques.

http://ploum.frimouvy.org/?2005/11/27/81-le-son-sous-ubuntu-breezy