mururoa69 a écrit 287 commentaires

C'est tout à fait un serveur mais le mien à 32 MB et un ARM à 200 MHz alors si je mets apache dessus il va s'écrouler. De toute façon apache n'est pas disponible sur sa distribution vu la puissance de la bête.

J'ai testé vite fait et ça devrait aller. A vérifier.
Le seul truc marrant c'est que si un agenda est stocké sur un partage samba du style h:\sunbird\ alors il faut indiquer file:///h:/sunbird/ sinon on se prend une méga erreur javascript parfaitement incompréhensible.
M'enfin, c'est peut-être marqué dans le manuel aussi.
Ah, j'ai comme l'impression qu'il n'y a pas de manuel, juste une faq et que c'est pas dedans.
Et ouais, je sais, si je ne suis pas content j'ai qu'à écrire un manuel ...

Sunbird devrait aller. Sans partie serveur. Avec juste les fichiers sur un NAS et en synchronisant les clients régulièrement.

Y a pas bande de ploucs, vous devriez devenir consultants.
C'est des remarques intelligentes, constructives et bien dans l'esprit d'entraide du libre.
Bravo les gars.
Si vous n'avez rien à dire vous n'avez pas à utiliser des posts sérieux pour vous défouler en vous moquant.

Le webdav est indispensable si sunbird n'est utilisé qu'en réseau local ?
On peut superposer facilement plusieurs agendas ?

J'ai juste oublié un truc : je ne veux pas de solution online du style google agenda ou autre.

J'ai indiqué mes soucis avec la méthode get-selections / set-selections plus haut.
Ta méthode marche mais ça ne correspond pas à notre façon de déployer les serveurs ici (preseed).
Voir plus, haut, mon problème est quasi-résolu avec les snapshots.

Je crois que ça répond à 99% à mon problème.
Reste 1% que je peux faire moi-même avec un peu de temps et d'efforts.
T'avais trouvé l'information sur ce serveur où ?
C'est dingue, on rentre n'importe quelle date et ça marche ...

Là j'ai etch + lenny + etch security + lenny security avec une seule architecture et les sources et ça pèse 107 GB.
Mais l'idée peut-être de ne pas prendre les sources oui. Reste à savoir si je peux m'en sortir sans.

Cf mon commentaire plus haut. Le problème de cette méthode c'est la taille du miroir en question.

Ouais, un dépot debian complet mono version ça pèse dans les 50-60 GB ;)
Autrement oui c'est une solution que j'utilise par exemple avec redhat mais là un dépot complet c'est genre 3-4 GB donc c'est jouable.

Oui j'y ai songé mais d'une part ça me complique sérieusement le processus de déploiement (preseed) et d'autre part ça pose problème avec l'installation après coup d'autres paquets debian qui risquent d'entraîner des mises à jour de librairies non souhaitées voire des mises à jour en chaîne.

Ca m'a l'air intéressant mais avec la racine de l'URL que tu donnes je n'arrive que sur une page nommée projects / et rien qui ressemble à des snapshots avec des dates et avec l'URL http://snapshots.debian.net/archive j'ai juste un Not Found.

Euh, là je parie ma chemise que tu n'as pas à gérer des serveurs en production ;)
En bref, un serveur en production est testé et validé avec une version particulière de l'OS associée à une version particulière des applications qui tournent dessus et il est hors de question de faire des mises à jour 'à l'arrache' en espérant que tout va continuer à tourner comme avant.
Quand les développeurs ont validé une appli sur un serveur de dev il faut installer le serveur de production à l'identique du serveur de développement ou au plus proche sinon on a droit à repasser par une phase de validation.
Chaque nouvelle version de l'application passe par la phase de validation. Chaque évolution de l'OS aussi.
Le serveur que tu mets à jour toutes les semaines s'appelle un serveur de test ou une machine perso si tu aimes les ennuis.
Personnellement j'ai eu le cas d'une application (non fournie par debian) qui ne fonctionnait plus du tout après une mise à jour d'une debian etch (pour des histoires de dépendances de librairies).

C'est en rapport avec des clusters linux sur VMware et le comportement des contrôleurs 'physical'.

Euh ouais, je connais très bien le SCSI hein ;)
C'est très facile d'avoir l'information sur l'ID du contrôleur sur Unix mais là sur Linux je sèche.

scsiadd -s ?

Parce que ça renvoi juste l'équivalent de cat /proc/scsi/scsi et c'est tout. Que les devices et pas le contrôleur.

Ca c'est quand même du fric dépensé pour rien vu que OpenVMS est toujours là et en pleine forme. Après probablement que le hardware était obsolète mais ça aurait probablement coûtè bien moins cher de juste changer le hardware qu'ils ont acheté de toute façon.
A savoir, HP/UX et OpenVMS tournent sur le même hardware : les serveurs à base d'itanium 2 de chez HP.

T'as un lien sur l'annonce sur support full pour les redhat 4 et 5 ?
Je n'arrive pas à trouver l'annonce.

Le piège réside très probablement dans sa complexité d'implémentation et ne concerne donc pas les utilisateurs.
HP qui détenait la technologie a été incapable de l'intégrer comme filesystem dans HP/UX et a dû continuer à payer une licence à Veritas pour proposer VxFS.
A moins que ce n'ait été culturel chez HP. Une grosse mauvais volonté quoi ou un manque de compétence à trop avoir viré d'employés (dont myself).
Wait & see.

Tru64 n'a pas été abandonné LORS du rachat de Compaq par HP mais bien après. Lors du rachat HP avait promis à ses clients de continuer à développer Tru64 en parallèle avec HP/UX puis de progressivement fusionner les deux OS. Quelques mois après il était question d'abandonner Tru64 en intégrant ses meilleures parties (TruCluster, AdvFS, LSM, ...) dans HP/UX. La troisième étape a bien été l'abandon pur et simple de Tru64 avec toutes les technologies afférentes au profit de HP/UX. Les clients ne s'y sont pas trompé d'ailleurs. A la question "avec quel OS allez-vous remplacer vos serveurs Tru64" la réponse des clients a été :
1er : AIX
2eme : linux
3eme : solaris
4eme : HP/UX

Euh, je ne vois pas d'inconvénient majeur. Ajout/suppréssion de volume en ligne, défragmentation en ligne, répartition des données globales ou par fichier sur les différents volumes, partition dynamique des volumes logiques, paramétrage fin, j'en passe et des meilleures.
Fiable, performant, souple et simple à utiliser.
Supérieur à tout ce qui existe sauf peut-être zfs (il faudrait un expert pour faire sortir les différences et les avantages comparatifs) mais bien plus mature et moins complexe à utiliser.

Attention ne pas faire de bonding en redhat 5.
Ca merde grâve ... Même en 5-2.
C'est con, ça marchait en redhat 4.
D'ailleurs je m'en vais de ce pas logger un problème sur le support redhat.

Ben voilà, tu sais pourquoi c'est pas cher maintenant. Il manque des bouts de trucs utiles. Presque jamais utiles mais indispensables quand t'es dans la merde ...

Euh, minute, en 2 minutes chez OVH je vois 2 trucs :
- vKVM
- reboot du serveur à distance

T'es sûr que t'as bien RTFM ?

Les cartes CF ne sont pas étudiées pour donc tu peux espérer deux choses :

- un débit pourri
- une durée de vie limitée

Maintenant si c'est pour mettre dessus des données relativement statiques ça peut être quand même intéressant en consommation et temps d'accès.