Aujourd'hui dans « Régis est un con ! »…

La vache, c'est violent, jamais il ne me viendrait à l'idée de faire ça sans communiquer d'abord!!
Quoique certains collègues de mon équipe, maintenant que j'y pense...

Si j'ai bien compris deviné, le filtre se fait sur l'adresse IP locale et les machines sont en IP variable?
Et donc à chaque re-boot l'ordi peut perdre la connexion en se faisant attribuer une "mauvaise" IP?

Si c'est bien ça, je vois un autre PEBKAC pour l'admin.

Quel que soit la méthode de filtrage, IP, MAC, RADIUS ou Tartan-pion... quand on effectue ce genre de manipulations sur un réseau, le minimum est d'informer tout le monde pour qu'en cas de problèmes ils sachent vers qui se retourner.

Faire tout et n'importe quoi dans son coin sans jamais prévenir qui que ce soit, c'est une spécialité dans certaines boîtes, malheureusement... :(

Donc tu es stagiaire et tu te permet de réinstaller un OS sur une machine mise à ta disposition. Tu risque de te faire des amis parmi les sysadmin...

Chez moi, le switch te dit "va te faire f.* et tu peux te brosser pour recup un accès a autre chose qu'un client leger.
Si on te donne une nouvelle chance.

J'suis en train de réaliser que sur les 3 stages que j'ai faits devant un pc dans ma jeunesse, y'en a eu 2 où j'ai installé un autre OS en dual boot sur la machine (et pété le windows qui était présent), et 1 où je venais avec ma propre machine... PUNK IS NOT DEAD o/

Réinstaller un os pour un problème simple de connexion réseau?
Est-ce vraiment un effort en relation avec le soucis?

Je ne vote ni l'un ni l'autre, parce que tu avais une carte réseau pleinement fonctionnelle. Tu pouvais lui attribuer une adresse IP à la main, faire quelques tests avant de tout réinstaller, surtout si ça avait déjà fonctionné correctement.

Et tu aurais vite vu qu'il s'agissait d'un problème indépendant de ta machine.

Perso j'ai installé moi-même mon système à mon stage de licence, et j'ai changé d'ordi à ma convenance à mon stage de DUT.

Tu ne connais absolument pas les circonstances pour juger.

Vu qu'il y a certainement du DHCP derrière, bonne chance pour trouver la bonne IP à mettre, dans la plage DHCP, non utilisée, et valide pour le serveur.

si l'admin est compétent, la manoeuvre est impossible. Chez nous, le bios possède un mot de passe et il n'est pas possible de booter sur autre chose que le HDD.

Et aller te renseigner auprès de l'administrateur, avant de tout réinstaller sur la machine, c'était pas possible ?
Voire avant même de décider d'installer un Linux, si c'était une machine du laboratoire.

C'était dans un petit labo. On travaille sur du bas niveau, on a besoin d'installer divers éléments (librairies, etc.) quasiment quotidiennement. Encore heureux qu'on ait l'accès root, et même aux partitions et autres. On n'est pas ici sur une utilisation de l'informatique de type secrétaire/bureautique, mais développement. L'ordi n'est pas seulement l'outil de travail, mais fait partie du processus de développement.

Faut arrêter de vouloir tout verrouiller, je suis carrément heureux de pouvoir faire ce que je veux sur ma machine sans avoir à faire une requête sysadmin 3 fois par jour pour installer un librairie.

+1
ping est notre ami ;-)

Il s'agissait tout simplement d'un DHCP attribuant l'adresse IP sur la base d'une adresse MAC.
Adresse MAC pas enregistrée = pas d'adresse IP = pas d'accès réseau.

Compétent pour quoi ? Pour empêcher de travailler correctement ?

J'ai eu peur d'avoir "tout cassé"...
Le PEBKAC est aussi pour moi sur ce coup là.

Quel administrateur ? Il y avait un admin "réseau", qui était en fait un McF qui faisait ca en plus de son boulot. Il était présent environ 1/2 journée par semaine, et était déjà parti quand j'ai découvert le problème.

L'administrateur des machines, c'est leur utilisateur.

L'ordi est un outil de travail. Tu demande la permission au chef de chantier avant de changer la mèche de ta perceuse ? Pour le boulot que je faisais, c'est du même ordre...

Je précise le contexte :

Petit laboratoire (une 20aine de personnes). L'administrateur réseau est un maître de conférences qui s'occupe du réseau en plus de son boulot de recherche/enseignement. Il avait mis en place une procédure de déclaration des machines (juste lui envoyer un mail avec nom de la machine, adresse MAC, etc.), et avait du en parler à quelques collègues, mais n'avait rien officialisé. Du coup, tout le monde n'était pas au courant.

Or, comme les machines sont achetées directement par les chercheurs, sur les divers contrats (thèse, projets ANR, etc.), voire étaient des machines personnelles (BYOD), la liste des machines déclarées était en fait carrément incomplète.

Pour le petit plus, ce collègue était rarement présent au labo, et son passage suivant s'est fait 2 semaines plus tard... 2 semaines sans réseau. En attendant, j'ai connecté mon ordi portable au wifi (wifi commun à toute l'université, donc accessible avec mon mdp), partagé la connexion, et branché l'autre ordi directement au portable par Ethernet en attendant... Gros bricolage donc, mais qui m'a permis d'installer les librairies et logiciels nécessaires.

Les VM tu connais ?

Quelle bonne idée !
Utilisons des VM pour travailler quotidiennement. Je vais donc tous les jours booter Windows, puis booter ma VM, et travailler exclusivement sur la VM. N'utilisons surtout pas les capacités natives de l'ordinateur, ajoutons des couches et encore des surcouches.

Pour info, je faisais des simu qui duraient 4 heures et consommaient environ 8 Gio de RAM. Je n'ose même pas imaginer la durée de celles-ci dans une VM.

?!?
Pour autant que je sache, installer un dual boot ne change pas l'adresse MAC de la carte réseau.
Et si la connexion réseau fonctionnait avant d'installer le dual boot, c'est que la carte avait une adresse MAC enregistrée.
Même si Fedora changeait l'adresse MAC logicielle, l'adresse utilisée sous Windows (matérielle ou logicielle) ne devrait pas changer.


@OzoneGrif: Oui, l'admin aurait dû informer les utilisateurs, je n'ai jamais dit le contraire.

L'adresse MAC n'a pas changé, il s'agit d'une malencontreuse coïncidence temporelle entre mon action et celle de l'admin réseau, qui a fait que j'ai cru que c'était de ma faute (pour le coup, un gros PEBKAC pour moi pour avoir cru que l'install de Linux avait causé un problème), alors que c'était celle de l'admin (PEBKAC aussi pour lui).

@Epok__ : "Utilisons des VM pour travailler quotidiennement."
C'est justement ce que tout le monde fait quotidiennement chez nous. Plutôt que de reformater les postes à chaque projet on crée une nouvelle VM. Tout est sous Windows Server (les hôtes et les VM) et tout fonctionne très bien. Il suffit juste d'avoir des machines correctes et pas des bouses sous-dimensionnées.
Tout dépend du contexte après, mais si on veut pouvoir avoir un environnement le plus proche possible de celui du client, on ne va pas travailler directement sur les machines hôtes, on monte des VM.

J'avoue que j'exagérais un peu dans mon commentaire. Sous Linux, j'utilise une VM W7 pour utiliser la suite Office, par exemple.

Néanmoins, dans mon cas, je ne me vois pas travailler de base sur une machine virtuelle. Mes besoins en ressources de calcul sont énormes : en effet, avec un processeur récent et 16 Gio de mémoire vive, mes simulations prennent encore plusieurs heures pour simuler quelques µs de fonctionnement. Et je ne pense pas qu'il s'agisse de "bouses sous-dimentionnées".

Je voulais simplement signifier que cette manière de faire ne convient pas à tous les usages. Faire fonctionner ModelSim, sur des designs incluant un SoPC complet, sur une machine virtuelle, pour moi, c'est se tirer une balle dans le pied.

L'ironie de ma réponse était juste proportionnelle au dédain affiché par A-xis dans sa réponse.

Il s'agit simplement d'une solution simple et fonctionnelle : j'ai besoin de Linux, une fois mon environnement en place je n'ai pas besoin d'en changer tous les 3 jours (contrairement à toi où l'usage des VM se justifie totalement), je n'ai pas besoin de Windows... Autant installer Linux en natif, pas besoin de se prendre la tête.

Les VMs en développement, c'est mignon et bien pratique, mais ça rajoute des bugs.

Je me souviendrais toujours de ce problème de buffer réseau sur les paquets UDP qui délayait leur émission de 2 secondes, bug lié au driver fourni par les VMWare Tools. En VoIP, c'est une catastrophe. Il y a aussi de nombreux problèmes aléatoires de performance, très gênant dans les systèmes temps réel.

C'est assez fou de voir tous ces gens qui bossent en entreprise et qui ne peuvent imaginer que dans d'autres domaines on puisse avoir d'autres besoin, qui sont même désagréable et prétentieux en ne sachant rien des besoins spécifiques du monde de la recherche (en général) et plus encore dans le domaine d'Epok__ ( semble-t-il.)

Ce discours là je l'ai entendu des dizaines de fois. "Vos droits limités de merde m'empêchent de faire mon boulot". Oui mais travaillez du côté des sysadmin pour voir. L'openbar sur les machines utilisateurs vous apportera les surprises suivantes :
- Virus
- Logiciels qui n'ont rien à faire là (emule, counter strike...)
- Des dizaines de logiciels totalement inconnus qu'il faudra néanmoins retrouver et paramétrer le jour où la machine crashe (et là l'utilisateur dira "c'est votre boulot démerdez-vous")
- Gens qui traitent directement avec les éditeurs sans passer par le SI (j'ai vu une utilisatrice avec 3 logiciels métiers redondants, dont on ne connaissait absolument rien car "c'est l'éditeur qui a pris la main et me l'a installé il y a 5 ans)
- Les gens qui stockent plein de dossiers sur C
- Le collègue qui fait le même travail mais n'utilise pas les mêmes logiciels

Donc non quand je lis ça ça me fait sauter au plafond. SI tu touche ta bille au point de pouvoir te débrouille dans les situations décrites ci-dessus tant mieux, mais pour 95% des utilisateurs c'est la catastrophe assurée.

As-tu seulement lu mes autres commentaires concernant le contexte, avant de sauter au plafond ? On ne parle pas ici d'utiliser Excel, mais d'avoir une machine de dev fonctionnelle pour des besoins propes à chaque utilisateur. On est dans un labo de recherche, pas dans une administration. Plusieurs collègues développent eux-même les logiciels qu'ils utilisent...

De plus, comme dit et répété, il n'existe pas de sysadmin dans ce labo. Chacun est son propre administrateur.

C'est bien simple, sans droits d'amin, je ne peux pas travailler. Je ne parle même plus de travailler "correctement", mais de travailler tout court.