Catégorie : Ubuntu

Truc « Debian » mais qui irait pareillement à Ubuntu. Ou trucs Ubuntu-only, plus rare.

Catégories
Debian planet-libre.org reseau et sécu Ubuntu

Falling back to PORT instead of PASV mode

Raaah, je me trainais ce truc là depuis longtemps ; pourtant je sais parfaitement que le FTP est un de ces protocoles un peu pourris vis-à-vis des firewalls (et proxies), mais j’avais jamais rien fait pour m’arranger la situation.
Bref, l’occasion de faire un rappel – je passe la théorie car je donnerais dans l’à peu près, mais j’explique l’aspect pratique pour régler le problème titre de cet article.

Lorsque vous avez des problèmes de mode passif, actif etc en FTP, pensez à ceci.
Si quelqu’un veut poster en commentaire la théorie expliquant le problème, n’hésitez pas. Il me semble me rappeler des histoires de trames FTP contenant les IP émettrices et donc nécessité d’avoir des modules de masquerading particulier pour bien gérer le FTP… un vague résidu de cours de réseau 🙂

La configuration

J’ai un serveur avec :

  • un FTP – restreints à certaines IP, rappelez-vous que FTP n’est pas du tout sûr (mot de passe en clair) et qu’il vaut mieux privilégier SFTP (du FTP par dessus SSH),
  • un shorewall ouvrant les ports 20 et 21

    • Bref que du bonheur en apparence.

    Le problème

    Malgré ça, je galère toujours d’un client FTP à l’autre. Le dernier en date : ncftp pour des échanges depuis un LAN vers ce serveur public. Ca se traduit par un cafouilli général dans les modes passifs etc.
    Et un message d’erreur que pour une fois, j’ai relu lentement et me suis rappelé le coup du NAT spécifique FTP :

    Falling back to PORT instead of PASV mode

    En soit, je me foutais de savoir comment le client FTP établissait sa connexion, car dans tous les cas ça marchait, ça restait sécurisé dans la limite de ce que je demandais, mais c’était surtout que la complétion de nom, style cd rep TAB-TAB-TAB mettait 20 secondes à répondre le temps de passer en mode « PORT » justement. Soit environ 19,8 secondes de trop.

    Comment on le règle ?

    On pense à activer le NAT spécifique au protocole FTP, dans netfilter. Pour ce faire, par exemple via l’outil modconf (ou sudo modconf chez Ubuntu) afin d’activer ces 2 modules :
    ./kernel/net/netfilter/nf_conntrack_ftp.ko
    ./kernel/net/ipv4/netfilter/nf_nat_ftp.ko

    Point besoin de rebooter, rien.
    Voilà, un protocole FTP mieux géré par firewall netfilter sur votre serveur.

    Excusez-moi pour l »à peu près technique concernant cet article. FTP ça me gave, c’est un sac d’ennuis ce truc. Mais c’est pratique.

    Catégories
    coup de coeur ligne de commande Ubuntu

    Bip, < tab >, bip, < tab >, bip, < tab >, bip……

    Pense-bête tout con mais ça fait tellement de bien : pour couper les p#*_ »~s de bips de votre shell ou de n’importe quelle fenêtre – je parle sous Ubuntu, allez dans Système -> Préférences -> Sons puis onglet « Bip système » et désactiver le truc qui va bien.

    Je ne sais pas comment j’ai fait pour tenir si longtemps avec cette horreur.

    (et avec modconf, vous pourrez virer une bonne fois le module pcspkr (« PC Speaker »), section kernerls/drivers/input/misc – yarglaaaaa)

    • Étiquettes
    Catégories
    Debian planet-libre.org Ubuntu

    Bloquer Hamachi au niveau shorewall et squid

    Sympa Hamachi, j’en parlais dans un précédent billet pour l’aspect « je joue en réseau avec mes potes ».

    => Aujourd’hui, j’en parle pour bloquer cette saloperie 😉 d’outil qui peut apporter de gros ennuis au boulot 🙂

    Pour rappel, c’est un VPN « zero-conf » qui permet à l’utilisateur nullissime en informatique (c’est-à-dire que vous n’avez rien besoin de connaître en info pour installer/utiliser ce truc) d’installer un VPN pour atteindre ses copains au boulot ou son PC chez lui. Au-delà de ça, ça peut rapidement se transformer en une passerelle entre un réseau bien sale (celui de l’utilisateur lambda chez lui, nul en informatique je le rappelle) et votre entreprise. D’où problèmes. D’où envie de donner des baffes.

    Voici comment le bloquer (du moins maintenant il ne passe plus à mon boulot et pourtant il essaye – donc je dois avoir fait le tour de la question), tant au niveau shorewall – si l’accès Internet est direct – qu’au niveau squid si vos utilisateurs *doivent* passer par le proxy pour atteindre Internet.

    Analyse à 2 balles du comportement de hamachi pour mieux le bloquer

    Au départ, installez hamachi pour tester. Ca devrait se connecter sans problème. Je pense qu’il va chercher la conf proxy dans les paramètres de IE.
    C’est typiquement le genre d’outils qui a prévu tout un tas de modes de connexions genre :
    – essayer tout un tas de ports standards
    – avoir plein de noms de machines pour atteindre le serveur par plusieurs chemins

    MAIS, comme c’est un outil avec un point central (le serveur chez eux pour s’authentifier – puisque ça a une vocation commerciale, payante, tout ça), on peut à un moment donné repérer tous les serveurs centraux et les bloquer. C’est pas comme pour des protocoles décentralisés type peer-to-peer.
    Bon après, s’ils changent leurs noms ou IP tout le temps, ça peut devenir pénible.

    Une fois connecté, allez voir vos logs squid, vous devriez voir tout un tas de requêtes du style :

    1221661590.889 350758 votre.ip.sur.lan TCP_MISS/200 3734 CONNECT ssl-24.hamachi.cc:443 - DIRECT/74.201.74.26 -

    De là, avec quelques commandes hosts, genre :

    for i in `seq -f '%02g' 1 40`
do
host ssl-$i.hamachi.cc
done

    Ainsi que :

    for i in `seq 1 255`
do
host 74.201.74.$i
done

    Ce qui donne :

    ...
103.74.201.74.in-addr.arpa domain name pointer ns3.3amlabs.com.
104.74.201.74.in-addr.arpa domain name pointer www02-09.logmein.com.
105.74.201.74.in-addr.arpa domain name pointer www02-09.logmein.com.
106.74.201.74.in-addr.arpa domain name pointer www02-09.logmein.com.
...

    Vous verrez qu’en gros, la plage IP 74.201.74.0/24 est à eux et qu’avec 4/5 noms de domaines génériques, vous pourrez tout bloquer.

    Blocage niveau shorewall

    En considérant que votre shorewall fonctionne bien, vous pouvez soit blacklister dans le fichier /etc/shorewall/blacklist (si vous avez bien activé l’option « blacklist » dans le fichier /etc/shorewall/interfaces), soit faire une règle dans /etc/shorewall/rules.
    Dans « blacklist », ajoutez la ligne :

    74.201.74.0/24

    Ou, dans « rules », ajoutez :

    DROP    lan     net:74.201.74.0/24      all

    Relancez shorewall via /etc/init.d/shorewall reload

    Blocage niveau Squid

    Allez dans le fichier /etc/squid/squid.conf et à l’endroit où sont définies des « ACL », ajoutez celles-ci – c’est un exemple à adapter.

    acl tout_mon_lan src 172.16.0.0/255.255.0.0
acl vilain_hamachi dstdomain .hamachi.cc .logmeinhamachi.com .logmein.com .3amlabs.com logmeinrescue.com logmeinrescue-enterprise.com
http_access deny tout_mon_lan vilain_hamachi

    Ici je me base sur les noms de domaines, pas les IP. C’est un choix motivé par le fait que le client hamachi semble tenter des noms de machines, pas des IP. A voir si l’éditeur fait évoluer ça dans le temps.
    Et pensez à recharger squid : /etc/init.d/squid reload

    Validez que ça ne marche plus

    Retestez la connexion à Hamachi. Vous devriez le voir s’exciter dans les logs squid sur quelques ssl-xx.hamachi.cc pris au hasard puis plus rien :

    1221666080.309      0 votre.ip.sur.lelan TCP_DENIED/403 1441 CONNECT ssl-14.hamachi.cc:443 - NONE/- text/html
1221666199.615      0 votre.ip.sur.lelan TCP_DENIED/403 1441 CONNECT ssl-15.hamachi.cc:443 - NONE/- text/html
1221666283.816      5 votre.ip.sur.lelan TCP_DENIED/403 1441 CONNECT ssl-13.hamachi.cc:443 - NONE/- text/html

    En images, ça reste sur ça :
    Hamachi bloqué

    Catégories
    bureautique coup de gueule Debian planet-libre.org Ubuntu windows

    Firefox 3, ça poutre… ou pas

    Génial le « download day ». Un concept. Non je déconne, en fait, je m’en tape… comme l’euro 2008, rien à foot.
    Néanmoins, comme je trainais sur portableapps et que FFox 3 portable est sorti très vite, j’ai tenté ma chance. Donc en sauvegardant mon Firefox 2 avant, bien au chaud, sentant le coup venir.
    Bilan des courses, une fois mes modules capitaux invalidés (all-in-one gestures, tabmix plus, google browser sync et celui d’ebay il me semble), voire d’autres, je ne sais plus car tout a été très vite, je suis revenu bien vite vers firefox 2.
    Quand je vois des plug-ins inutiles comme Vimperator sont dispos pour ffox 3, j’ai mal de voir les autres non dispos. Bon certes, je gueule mais je ne développe rien. Oui en effet, mais bon j’aime pas trop me sentir pris au piège, on dirait du bigrozoft : migrez les gars, on verra après…

    Allez-y, excitez-vous, d’ici 1 mois, je retrouverai mes modules et hop, à moi firefox 3…
    Et après on se demande pourquoi je préfère Debian à des distrib un peu trop vivaces. Heureusement, mon Ubuntu est restée en 7.10, je me méfie de la migration en 8.jesaisplusquoi. A tous les coups y’a ffox 3 dedans maintenant et pan dans ta gueule les modules, de force.

    Beta-deployez bien, a+

    Catégories
    coup de gueule ligne de commande Ubuntu

    « Ubuntu UTF-8 » VS. « le reste en iso-8859-1 »

    Cher blog,

    Je t’écris car je suis globalement très content de mon Ubuntu, mais l’UTF-8, j’en ai pas besoin et dès que je fais du FTP, SFTP etc avec un système non-UTF-8, ça me fout en l’air les accents. Et des accents, j’aime bien en avoir.
    Alors bon, j’ai bien trouvé un article sur un forum Ubuntu permettant de passer mon Ubuntu en iso-8859-15, mais ça a plutôt foiré qu’autre chose.
    Je suis donc revenu en arrière, je conserve ma distrib en UTF-8 des fois que je me mette au Japonais un jour, et je cherche plutôt à utiliser mes clients FTP en mode iso-8859-1. Ca me parait plus sain.

    Maintenant que j’ai à peu près trouvé tout ce que je voulais, je peux taper sur mon NAS en retrouvant mes accents, ainsi que sur ma dedibox, elle aussi en iso-8truc.

    Dans l’explorateur de fichiers de Ubuntu (gnome)

    Lorsque je tape une URL du type ftp://login:pass@machine/ je n’ai pas trouvé où mettre un paramétrage sur le jeu de caractères…

    Dans gFTP

    Dans les options, on peut préciser un jeu de caractère et la conversion se passe bien

    Dans lftp

    Comme je suis adepte du mode texte et de screen, il fallait aussi que ça marche avec lftp. Pour trouver, j’ai tapé sous le prompt de lftp un beau set -a | grep char pour repérer le paramétrage qui allait bien. Ensuite, j’ai ajouté les deux lignes suivantes dans le fichier /etc/lftp.conf :

    set ftp:charset iso-8859-1
set sftp:charset iso-8859-1

    Voilà. Ca va être marrant à imposer l’UTF-8….. et puis tant que Windows n’y sera pas, la majorité de la planète n’y passera pas. Enfin bref, de gros trolls poilus en perspective. Moi ça me gave ces gue-guerres…

    Et quelques jours après….

    Ben finalement je commence à ne plus mettre d’accents nulle part. J’ai moins d’emmerdements…

    Si quelqu’un a une doc biblique sur « comment ne pas être emmerdé par l’UTF-8 », je suis preneur.

    Catégories
    Debian planet-libre.org reseau et sécu Ubuntu

    A propos de la fameuse faille OpenSSL sur Debian et dérivés

    L’histoire en quelques mots

    Bon, je poste un peu après tout le monde sur le sujet. Mais c’est histoire de faire part de 2/3 remarques. A voir les news postées un peu partout, j’ai l’impression de revivre la naissance de « Blaster » sous Windows : grande ampleur alors que la correction existait et beaucoup découvrent/découvraient ça tardivement sans trop savoir quoi faire.
    Bon ici, il ne s’agit que de rectifier avant qu’une faille soit exploitable. Mais c’est extrêmement préoccupant.
    Et le pire, c’est que contrairement à beaucoup de failles, le problème réside dans les « clefs de cryptage » que vous utilisez (qui vous sont propres), pas dans l’outil en lui-même. Donc appliquer les patchs constitue seulement 1% de la solution. (dans le cas où vos clefs ont été générées, disons, entre hier et y’a 2 ans… c’est large)

    Point de départ de l’information

    Si vous découvrez seulement maintenant le sujet et que vous gérez des Debian ou Ubuntu ou dérivés, c’est grave, lisez vite les « security advisory » de openssl et de openssh publié le lendemain. Ce sont les seules sources fiables, comme point de départ.
    Si ça vous gonfle car c’est en anglais, parce-que personne n’en voudrait à votre pseudo-serveur etc, alors arrêtez tout de suite de « gérer » un serveur…
    Le wiki de Debian résume bien tous les services qui peuvent être impactés et donnent les opérations à faire. A commencer par OpenSSH (tout le monde l’a celui-là)

    Donc, pour cette fois, et pour les suivantes, faites ceci :

    Pour bien réagir la prochaine fois :

    Inscrivez-vous sur la mailing-list de securité Debian

    Inscrivez-vous soit par l’interface web, soit en envoyant un mail à debian-security-announce-REQUEST@lists.debian.org avec sujet subscribe et en confirmant une fois le 1er de retour reçu).
    Optez pour celle appelée « debian-security-announce », pas nécessairement « debian-security » qui est plutôt une chat-room non modérée 😉
    => Ainsi, vous serez au courant au bon moment avec les bonnes infos, plutôt que des « on dit » incomplets sur des forums.
    Si vous n’êtes pas en Debian, ça vaut quand même. Il doit y avoir l’équivalent sur Ubuntu et autres dérivés.

    Lisez les alertes à tête reposée et faites ce qui est demandé

    Par exemple, dans celle d’OpenSSL dit notamment une toute petite phrase : « We recommend that you upgrade your openssl package and subsequently regenerate any cryptographic material, as outlined above. »
    => Cette toute petite phrase veut simplement dire qu’il faut regénérer TOUT ce qui a trait à la crypto. Donc tous vos certificats pour vos protocoles sécurisés, notamment SSH, HTTPS, POP3S, IMAPS, SSMTP etc. Sans parler des known_hosts et authorized_keys. En gros, si vous gérez un paquet de serveurs, ça va juste vous pourrir un bon paquet d’heures. Mais c’est obligatoire.

    Le mot de la fin

    Voilou, c’était histoire de clarifier la situation vu ce qu’on peut lire comme info incomplète sur cette faille. Le classique "apt-get update ; apt-get upgrade" du matin ne suffit pas !
    J’ai eu envie de faire cet article quand je pense aux hébergeurs qui proposent des serveurs à pas cher, avec environ 97% d’admin archi-débutant-pas-sérieux. Je me ferais du souci à leur place. Surtout si un exploit est révélé !
    Faites que le mien ne bloque pas le trafic SSH en cas d’exploit révélé (si si, mon hébergeur l’a proposé, arg !)…. ce serait un bordel sans nom.

    Catégories
    autres outils bugs ligne de commande planet-libre.org Ubuntu

    GRUB avec un disque SAS, des SATA et un BIOS un peu pourri

    Voici un petit retour d’install-galère. Le but est de rappeler 2/3 arguments de GRUB bien pratiques et de faire remarquer quelques bizarreries du monde PC, dirons-nous.

    Récemment, j’ai installé une Ubuntu sur un PC équipé comme suit :
    – disque 1 : SAS (Serial-Attached-SCSI) contenant un windows
    – disque 2 : SATA vide prévu pour l’Ubuntu
    – disques 3 et 4 : 2 HD SATA de données.

    Il n’y avait donc qu’un boot XP normal sur le SAS.

    Ordre de boot…

    Au départ, le BIOS (d’une marque connue qui ne permet rien ou si peu dans son BIOS) pointait sur le SAS puis SATA dans l’ordre de boot.
    J’ai choisi de mettre GRUB sur le disque SATA (et ainsi ne pas flinguer le MBR du Windows). Comme ça les OS ignorent presque que l’autre est là et je peux surtout virer un des 2 disques sans devoir réinstaller le MBR de l’un ou de l’autre.

    J’ai donc dû inverser l’ordre de boot dans le BIOS. Rien de surprenant jusque là.
    Comme on ne peut pas préciser dans ce BIOS quel SATA ou quel SAS doit booter lorsqu’il y en a plusieurs, c’est donc le premier – pas d’autre possibilité.
    Ce premier détail – on s’en rend compte après une première install d’Ubuntu sur le SATA où rien ne boote – force à organiser ses disques (mes SATA en l’occurrence) de sorte que l’Ubuntu soit sur le premier SATA. Au départ, dans mon cas, c’était le dernier (je venais de l’ajouter…)

    sda, non, sdd, non (hd3,0) non plus… raaaaaah

    J’ai fait plusieurs réinstall de la chose et ça ne s’est pas vraiment passé 2 fois pareil au niveau de la détection des disques durs, donc de l’ordre d’apparition, donc de leurs noms, donc de la conf GRUB. Parfois tout marchait tout seul, parfois après install, plus rien ne bootait (ni Ubuntu, ni Windows).
    Un conseil donc, avant de lancer l’installation Ubuntu, lorsque vous êtes en liveOS, vous repérez bien le nom de chaque disque via un petit fdisk. Vous le faites avec le BIOS précablé vers le bon disque (mon SATA dans mon cas) :

    ubuntu:~$ sudo fdisk -l
Disque /dev/sda: 146.8 Go, 146815737856 octets
255 heads, 63 sectors/track, 17849 cylinders
Units = cylindres of 16065 * 512 = 8225280 bytes
Disk identifier: 0x12345678

Périphérique Amorce    Début         Fin      Blocs    Id  Système
/dev/sda1   *           1       17849   143372061    7  HPFS/NTFS

Disque /dev/sdb: 400.0 Go, 400088457216 octets
255 heads, 63 sectors/track, 48641 cylinders
Units = cylindres of 16065 * 512 = 8225280 bytes
Disk identifier: 0x12345678

Périphérique Amorce    Début         Fin      Blocs    Id  Système
/dev/sdb1   *           1        2432    19535008+  83  Linux
/dev/sdb2            2433        2681     2000092+  82  Linux swap / Solaris
/dev/sdb3            2682       48641   369173700   83  Linux

Disque /dev/sdc: 400.0 Go, 400088457216 octets
255 heads, 63 sectors/track, 48641 cylinders
Units = cylindres of 16065 * 512 = 8225280 bytes
Disk identifier: 0x12345678

Périphérique Amorce    Début         Fin      Blocs    Id  Système
/dev/sdc1               1       48641   390708801    7  HPFS/NTFS

Disque /dev/sdd: 400.0 Go, 400088457216 octets
255 heads, 63 sectors/track, 48641 cylinders
Units = cylindres of 16065 * 512 = 8225280 bytes
Disk identifier: 0x12345678

Périphérique Amorce    Début         Fin      Blocs    Id  Système
/dev/sdd1               1       48641   390708801    7  HPFS/NTFS

    Dans le cas ci-dessus, le SAS de 146 Go puis 3 SATA de 400 Go.
    Donc Windows = /dev/sda1 et Ubuntu sera = /dev/sdb1

    FIXME : Parfois, et je n’arrive pas à l’expliquer, le boot du Live Ubuntu m’a sorti un mode graphique un peu dégradé et l’ordre des disques changeaient…
    Au final, je me suis retrouvé avec une conf GRUB mauvaise et pas grand chose ne bootait.

    Dans mon cas, la bonne conf est la suivante – je ne prends que la fin du fichier /boot/grub/menu.lst :

    ## ## End Default Options ##

title           Ubuntu 7.10, kernel 2.6.22-14-generic
root            (hd0,0)
kernel          /boot/vmlinuz-2.6.22-14-generic root=UUID=52f30332-a489-4df5-8305-85c4a1e7dba1 ro quiet splash
initrd          /boot/initrd.img-2.6.22-14-generic
quiet

title           Ubuntu 7.10, kernel 2.6.22-14-generic (recovery mode)
root            (hd0,0)
kernel          /boot/vmlinuz-2.6.22-14-generic root=UUID=52f30332-a489-4df5-8305-85c4a1e7dba1 ro single
initrd          /boot/initrd.img-2.6.22-14-generic

title           Ubuntu 7.10, memtest86+
root            (hd0,0)
kernel          /boot/memtest86+.bin
quiet

### END DEBIAN AUTOMAGIC KERNELS LIST

# This is a divider, added to separate the menu items below from the Debian
# ones.
title           Other operating systems:
root


# This entry automatically added by the Debian installer for a non-linux OS
# on /dev/sda1
title           Windows XP
map             (hd3) (hd0)
map             (hd0) (hd3)
root            (hd3,0)
makeactive
chainloader     +1

    Le piège

    Si vous avez été attentif, vous avez vu le piège :
    Dans GRUB, le linux est vu comme le premier disque : hd0. C’est vrai, à condition de se dire que le BIOS boote (donc détecte ?) d’abord le SATA (donc il compte d’abord les SATA et le SAS est vu alors en 4è).
    => C’est sur cette info que se base GRUB.

    Par contre, le disque contenant vraiment l’OS Linux est sdB, donc le deuxième O_o
    => Ce qui veut dire que Ubuntu redétecte l’ordre des disques à sa manière ensuite (disons que je le vois comme ça, tout au moins 🙂

    De même pour le Windows, c’est sdA alors qu’il est vu par le BIOS en dernier (4è => hd3 dans GRUB).

    Enfin, piège ultime, les lignes « map » qui n’étaient pas là au départ.
    Windows ne tolère de booter que s’il est « le premier disque » – ce qui ne veut rien dire et est une limitation complètement débile. Toujours est-il que là, il est vu à un moment donné comme 4è et sans vous le dire, ce con de NTLOADER ne part pas (et ne vous dit rien). GRUB vous dit que ça merdoit puis vous ramène au menu de boot.
    La commande « map » sert à modifier virtuellement l’ordre des disques. Ca suffit à blouser Windows. Attention le « root » reste sur hd3 alors qu’on a inversé les disques, c’est pas dynamique à ce niveau là.

    => Le bilan après installation Ubuntu, c’est qu’aucun des menus ne menait à rien…. il a fallu changer la conf GRUB à la volée pour récupérer le linux, tester les paramètres pour booter le windows et enfin écrire la bonne conf dans /boot/grub/menu.lst

    Remarque sur les modifs à la volée de GRUB lors du boot

    Si GRUB démarre après une install, mais qu’aucun menu ne vous démarre un OS (ils sont simplement listés), n’oubliez pas que vous avez la touche ‘e’ pour éditer une des lignes du menu de choix du boot. Les raccourcis claviers sont expliqués. Vous pourrez donc choisir un root (hdtruc,bidule) qui va bien.
    Si vous avez bien en tête la conf en terme de /dev/sdX et l’ordre des disques vu par le BIOS, vous devriez pouvoir faire booter n’importe quoi. Une fois sous le linux qui héberge le fichier de conf de GRUB, vous reportez vos modifs et c’est fini.

    Catégories
    planet-libre.org Ubuntu

    Ubuntu (XUbuntu en fait) « persistant » sur clef USB

    Jusqu’à présent, j’utilisais une clef USB formattée DOS avec la distrib SLAX pour me faire un OS de dépannage de PC plantés. Je vous passe l’utilité de ce genre de LiveOS de rescue, vous devez connaître ça par coeur je pense.
    J’ai voulu installer une XUbuntu « persistante », c’est-à-dire « qui se souvient des modifications apportées à l’OS ». Avec ça donc, vous pouvez embarquer un LiveOS avec des données et des applications supplémentaires, mises à jour etc. Un vrai OS embarqué et vivant. Le pied total pour le geek qui sommeille en vous.

    J’ai trouvé plusieurs sites web tous un peu brouillons donnant des informations sur le sujet. Je vous fais une synthèse propre de la chose, fait avec une XUbuntu (plus légère qu’Ubuntu) 7.10 i386 desktop

    Lire la suite « Ubuntu (XUbuntu en fait) « persistant » sur clef USB »
    Catégories
    PS3 Ubuntu

    J’ai fait pété la PS3. Vive Linux.

    Et hop, j’ai lâchement profité d’amis s’étant cotisés pour ma décennie passée pour faire péter la TV qui va bien (full hd etc). Et comme Sony faisait une offre pour une PS3 packagée avec une TV de chez eux, j’ai fait pété la PS3 avec. Le tout dans l’espoir de remplacer mon lecteur de DVD, mon jukebox Rapsody (RSH-100) et de gratter au passage un lecteur blu-ray (une PS3 quoi), le tout en un seul périphérique.

    Et évidemment, d’installer Linux dessus…

    Lire la suite « J’ai fait pété la PS3. Vive Linux. »