Re: [FRnOG] [TECH] Juniper EX2300 /var/tmp : no space left -> can't load kernel
Bonsoir, On Thu, 1 Feb 2024 18:57:19 +0100 David Ponzone wrote: > PS: je peux te raconter des anecdotes sur Cisco, marque réputée aussi, si > tu as la nuit devant toi :) J'en ai aussi :D Paul --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Juniper EX2300 /var/tmp : no space left -> can't load kernel
Bonsoir, On Thu, 1 Feb 2024 18:50:24 +0100 Toussaint OTTAVI wrote: > Et qui, en plus, seraient, semble t-il, obsolètes en 2024. J'attends que > le commercial me rappelle :-D :-D :-D Si il lit la liste, tu peux attendre longtemps... Va ecouter les anecdotes de David, ca te fera patienter :) Paul --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Juniper EX2300 /var/tmp : no space left -> can't load kernel
800€ pour ça ? Et t’as acheté avant de jouer avec ? PS: je peux te raconter des anecdotes sur Cisco, marque réputée aussi, si tu as la nuit devant toi :) > Le 1 févr. 2024 à 18:50, Toussaint OTTAVI a écrit : > > > T'es gentil, mais ce sont des flambant neufs à 800 € qui m'ont été chaudement > recommandés après un Teams avec 4 commerciaux :-D > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Juniper EX2300 /var/tmp : no space left -> can't load kernel
Le 01/02/2024 à 18:13, David Ponzone a écrit : Je suis juste stupéfait par le temps que tu as à perdre là-dessus :) Bah, j'ai acheté ces trucs dans l'éventualité de remplacer ma marque actuelle qui me satisfait assez peu. Donc, j'y passe du temps, pour comprendre comment çà fonctionne, pour comprendre si c'est juste moi qui ai deux mains gauches, ou bien s'il y a autre chose. Le JunOS est tout de même quelque chose d'assez complexe, donc je n'entends pas l'apprivoiser sans y passer du temps :-) Et puis, je les ai achetés. Donc, j'aimerais bien arriver à les faire fonctionner quelque part, sinon, en plus du temps, ce sera aussi de l'argent doublement foutu en l'air (vu qu'il faudra que je rachète autre chose) (et vu les commentaires, je doute que quelqu'un ici me les rachète). Alors moi dans ce genre de cas, j’ai juste 2 réflexes: -ce temps que ça prend, il sert à rien, car le matos est clairement mal conçu, et un jour ou l’autre, ça va te retomber sur la gueule Bah, oui, en l'état, il ne me viendrait pas à l'idée de mettre çà en prod quelque part, c'est clair :-) Ceci étant, ce genre de feinte, on ne peut le découvrir qu'en testant :-) Je ne m'attendais clairement pas à çà venant d'une marque "réputée", et qui m'avait par ailleurs été recommandée ici... -le but c’est quoi: savoir si tu peux ré-utiliser des vieux Juniper à 50 ou 100 balles ? T'es gentil, mais ce sont des flambant neufs à 800 € qui m'ont été chaudement recommandés après un Teams avec 4 commerciaux :-D -je regarde sur Ebay, j’en vois presque pas à vendre, donc c’est un modèle qui a été peu diffusé, donc un jour tu en trouveras plus, galère pour les parts, etc… Et qui, en plus, seraient, semble t-il, obsolètes en 2024. J'attends que le commercial me rappelle :-D :-D :-D --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Juniper EX2300 /var/tmp : no space left -> can't load kernel
Toussaint, Je suis juste stupéfait par le temps que tu as à perdre là-dessus :) Alors moi dans ce genre de cas, j’ai juste 2 réflexes: -ce temps que ça prend, il sert à rien, car le matos est clairement mal conçu, et un jour ou l’autre, ça va te retomber sur la gueule -le but c’est quoi: savoir si tu peux ré-utiliser des vieux Juniper à 50 ou 100 balles ? -je regarde sur Ebay, j’en vois presque pas à vendre, donc c’est un modèle qui a été peu diffusé, donc un jour tu en trouveras plus, galère pour les parts, etc… > Le 1 févr. 2024 à 17:44, Toussaint OTTAVI a écrit : > > > Le 30/01/2024 à 10:39, Dominique Rousseau a écrit : >> Du coup, moi, si j'ai pas une vraie bonne raison d'utiliser "jweb" ( ca >> me fait penser à la webui du truc ), je le virerai, au moins pour voir >> ce que ca change. >> Ou au moins voir le menage qui peut etre fait dans ses fichiers ? > > En poursuivant mes tests sur mes EX2300, qui détiennent à ce jour le record > du temps passé en lab sans sortir quoi que ce soit de satisfaisant, j'ai > donc refait une installation complète, avec formatage, depuis une clef USB, > et sans aucun package supplémentaire (y compris J-Web). Config basique : 1 > vlan de management, un port connecté, SSH, NTP, et zéro trafic. > > show system storage : > /dev/gpt/junos 1.3G 518M 738M 41% /.mount > (soit à peine 20M de plus qu'avec mes tentatives précédentes avec J-Web) > > request system snapshot recovery > Creating image ... > Compressing image ... > Image size is 378MB > ERROR: The OAM volume is too small to store a snapshot > > Cette fois, on a donc une erreur différente. Il est allé plus loin. Il a eu > assez de place pour générer son dossier et pour le zipper. Ensuite, il > n'arrive pas à le copier sur la partition /oam, alors que la doc dit qu'il > est censé écraser automatiquement le précédent s'il y en a un (le précédent > fait à près près la même taille : 370M) > > Mais ce n'est pas le pire : > show system storage : > /dev/gpt/oam484M 459M -14.1M 103% /.mount/oam > > Ouch ! 103% ! -14M libre ? Cà veut dire qu'il a débordé de 14M sur la > partition d'après ??? > > Donc, je tente cette commande, qui est censée, si j'ai bien compris, > reconstruire une partition /oam propre : > request system recover oam-volume > Là, il se met à tourner. Un bon moment. Il affiche plein de trucs qui n'ont > rien à voir avec l'exemple de la doc. Je m'inquiète un peu, mais bon... > N'ayant d'autre choix à ce stade, je le laisse faire... > > Puis d'un coup, ventilo à fond qui me décalque les oreilles ! Je jette alors > un coup d'oeil sur la console : > Rebooting... > Can't load kernel ! > > Wow ! > > De toute ma vie d'informaticien, c'est le premier truc qui explose seul avant > même que j'aie commencé à le chatouiller ! :-D > > -- > Plus sérieusement : > Cà n'arrive qu'à moi, ce genre de truc ? :-) Faut-il que je me mette en > recherche d'un exorciste / chaman / mazzeru ? :-) Ou alors, il y a > réellement un problème de qualité ? Comment vous faites, tous les gens qui > en ont en prod ? Vous serrez les fesses à chaque mise à jour, comme avec > Windows ? :-) Vous re-flashez tout à chaque fois avec des clefs USB ? Vous > utilisez le truc mistique dans le nuage ? Vous n'utilisez que des très gros > modèles, qui sont plus fiables ? J'ai regardé les gammes au dessus, le > premier qui ait plus de 2 Go de stockage, c'est le EX4400, qui passe à 20 Go. > J'attends de voir ce que le commercial va me proposer ;-) > > > > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Juniper EX2300 /var/tmp : no space left -> can't load kernel
Le 30/01/2024 à 10:39, Dominique Rousseau a écrit : Du coup, moi, si j'ai pas une vraie bonne raison d'utiliser "jweb" ( ca me fait penser à la webui du truc ), je le virerai, au moins pour voir ce que ca change. Ou au moins voir le menage qui peut etre fait dans ses fichiers ? En poursuivant mes tests sur mes EX2300, qui détiennent à ce jour le record du temps passé en lab sans sortir quoi que ce soit de satisfaisant, j'ai donc refait une installation complète, avec formatage, depuis une clef USB, et sans aucun package supplémentaire (y compris J-Web). Config basique : 1 vlan de management, un port connecté, SSH, NTP, et zéro trafic. show system storage : /dev/gpt/junos 1.3G 518M 738M 41% /.mount (soit à peine 20M de plus qu'avec mes tentatives précédentes avec J-Web) request system snapshot recovery Creating image ... Compressing image ... Image size is 378MB ERROR: The OAM volume is too small to store a snapshot Cette fois, on a donc une erreur différente. Il est allé plus loin. Il a eu assez de place pour générer son dossier et pour le zipper. Ensuite, il n'arrive pas à le copier sur la partition /oam, alors que la doc dit qu'il est censé écraser automatiquement le précédent s'il y en a un (le précédent fait à près près la même taille : 370M) Mais ce n'est pas le pire : show system storage : /dev/gpt/oam 484M 459M -14.1M 103% /.mount/oam Ouch ! 103% ! -14M libre ? Cà veut dire qu'il a débordé de 14M sur la partition d'après ??? Donc, je tente cette commande, qui est censée, si j'ai bien compris, reconstruire une partition /oam propre : request system recover oam-volume Là, il se met à tourner. Un bon moment. Il affiche plein de trucs qui n'ont rien à voir avec l'exemple de la doc. Je m'inquiète un peu, mais bon... N'ayant d'autre choix à ce stade, je le laisse faire... Puis d'un coup, ventilo à fond qui me décalque les oreilles ! Je jette alors un coup d'oeil sur la console : Rebooting... Can't load kernel ! Wow ! De toute ma vie d'informaticien, c'est le premier truc qui explose seul avant même que j'aie commencé à le chatouiller ! :-D -- Plus sérieusement : Cà n'arrive qu'à moi, ce genre de truc ? :-) Faut-il que je me mette en recherche d'un exorciste / chaman / mazzeru ? :-) Ou alors, il y a réellement un problème de qualité ? Comment vous faites, tous les gens qui en ont en prod ? Vous serrez les fesses à chaque mise à jour, comme avec Windows ? :-) Vous re-flashez tout à chaque fois avec des clefs USB ? Vous utilisez le truc mistique dans le nuage ? Vous n'utilisez que des très gros modèles, qui sont plus fiables ? J'ai regardé les gammes au dessus, le premier qui ait plus de 2 Go de stockage, c'est le EX4400, qui passe à 20 Go. J'attends de voir ce que le commercial va me proposer ;-) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Juniper EX2300 /var/tmp : no space left
Le 30/01/2024 à 10:48, David Ponzone a écrit : C’est rigolo comme approche Dans mon monde à moi, c’est: il pète, il est remplacé. Bah, s'il pète électriquement, oui, il sera remplacé. Et en attendant, il y en a minimum deux en stack. Je parlais bien entendu de tester la résistance de l'OS, notamment à des coupures électriques intempestives / répétitives, voir si çà peut péter le filesystem principal, et si oui, voir si c'est facile ou pas de le réparer (notamment depuis la partition /oam). --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Juniper EX2300 /var/tmp : no space left
C’est rigolo comme approche :) Dans mon monde à moi, c’est: il pète, il est remplacé. > Le 30 janv. 2024 à 10:20, Toussaint OTTAVI a écrit : > > > > Le 29/01/2024 à 20:50, Pierre LANCASTRE a écrit : >> Ça n'enlève pas le fait que tu devrais pouvoir en faire, mais je me >> questionne :) > > Comme dirait l'autre : "poser la question, c'est y répondre" :-) > > C'est une première expérience, et un lab destiné à apprivoiser le JunOS dans > son ensemble, voir s'il se laisse dompter facilement, et quels sont les > problèmes potentiels. Le principe du recovery sur la partition dédiée OAM me > plaît bien. Donc, je voudrais que çà fonctionne ;-) C'est un peu comme > l'airbag sur les voitures. Personne ne souhaite avoir à le tester un jour en > conditions réelles. Mais pas grand monde non plus ne souhaitera prendre le > volant avec un voyant "airbag" allumé ! > > Une fois que toutes les options de sauvegarde, snapshot, recovery auront été > validés, on passera aux choses sérieuses, c'est à dire essayer de péter le > truc (redémarrages électriques répétitifs et violents, coupure des liens de > stacking...), et s'il pète, tester/valider les process de recovery. > > Suite à cela, il en résultera une "note de confiance", avec, j'en conviens, > une part de subjectivité, qui conditionnera l'usage futur qui en sera fait. > Ou pas. > > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Juniper EX2300 /var/tmp : no space left
Le Mon, Jan 29, 2024 at 04:52:34PM +0100, Toussaint OTTAVI [t.ott...@bc-109.com] a écrit: > > Le 22/01/2024 à 16:32, Toussaint OTTAVI a écrit : > >En regardant les points de montage d'un peu plus près : > >df -h | grep /tmp > > tmpfs 826M 16K 826M 0% /.mount/tmp > > /var/tmp 1.3G 544M 712M 43% > >/.mount/packages/mnt/jweb-ex-33d6a634/jail/var/tmp > > Je me casse toujours les dents sur mes EX2300, sur lesquels il n'y a pas > assez de place pour faire des snapshots recovery. Un suspect est le > /var/tmp, qui a un point de montage assez étrange (en sous-dossier du > package J-Web). Moi, je comprends ca dans l'autre sens, que le paquet jweb a un montage dans sa jail, qui partage l'espace du /var/tmp global Du coup, moi, si j'ai pas une vraie bonne raison d'utiliser "jweb" ( ca me fait penser à la webui du truc ), je le virerai, au moins pour voir ce que ca change. Ou au moins voir le menage qui peut etre fait dans ses fichiers ? -- Dominique Rousseau Neuronnexion, Prestataire Internet & Intranet 6 rue des Hautes cornes - 8 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Juniper EX2300 /var/tmp : no space left
Le 29/01/2024 à 20:50, Pierre LANCASTRE a écrit : Ça n'enlève pas le fait que tu devrais pouvoir en faire, mais je me questionne :) Comme dirait l'autre : "poser la question, c'est y répondre" :-) C'est une première expérience, et un lab destiné à apprivoiser le JunOS dans son ensemble, voir s'il se laisse dompter facilement, et quels sont les problèmes potentiels. Le principe du recovery sur la partition dédiée OAM me plaît bien. Donc, je voudrais que çà fonctionne ;-) C'est un peu comme l'airbag sur les voitures. Personne ne souhaite avoir à le tester un jour en conditions réelles. Mais pas grand monde non plus ne souhaitera prendre le volant avec un voyant "airbag" allumé ! Une fois que toutes les options de sauvegarde, snapshot, recovery auront été validés, on passera aux choses sérieuses, c'est à dire essayer de péter le truc (redémarrages électriques répétitifs et violents, coupure des liens de stacking...), et s'il pète, tester/valider les process de recovery. Suite à cela, il en résultera une "note de confiance", avec, j'en conviens, une part de subjectivité, qui conditionnera l'usage futur qui en sera fait. Ou pas. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Juniper EX2300 /var/tmp : no space left
Hello, Petite question : c'est quoi la cible de faire du snapshot sur ces gammes la ? Une sauvegarde de configuration auto et historisée + rescue config devraient suffire ? Ça n'enlève pas le fait que tu devrais pouvoir en faire, mais je me questionne :) J'ai rarement vu des switchs en carafe, à part les 4200 dans des vieilles versions de Junos, où tu gagnais une réinstall à la clé USB (suite mauvais reboot électrique) ++ Pierre Le lun. 29 janv. 2024 à 10:55, Toussaint OTTAVI a écrit : > > Le 22/01/2024 à 16:32, Toussaint OTTAVI a écrit : > > En regardant les points de montage d'un peu plus près : > > df -h | grep /tmp > > tmpfs 826M 16K826M 0%/.mount/tmp > > /var/tmp 1.3G544M712M43% > > /.mount/packages/mnt/jweb-ex-33d6a634/jail/var/tmp > > Je me casse toujours les dents sur mes EX2300, sur lesquels il n'y a pas > assez de place pour faire des snapshots recovery. Un suspect est le > /var/tmp, qui a un point de montage assez étrange (en sous-dossier du > package J-Web). > > Est-ce que l'utilisation du shell FreeBSD est supportée pour y faire des > choses au niveau de l'OS, comme par exemple modifier un fichier de > démarrage pour changer un point de montage ? Y a t-il des docs en ce > sens ? A quel endroit pourrait se trouver le montage du /var/tmp vers ce > chemin bizarre ? > > Merci par avance pour vos idées. Sinon, il ne me restera plus qu'à > attendre Vendredi pour poster une petite annonce en [BIZ] ;-) > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Juniper EX2300 /var/tmp : no space left
Le 22/01/2024 à 16:32, Toussaint OTTAVI a écrit : En regardant les points de montage d'un peu plus près : df -h | grep /tmp tmpfs 826M 16K 826M 0% /.mount/tmp /var/tmp 1.3G 544M 712M 43% /.mount/packages/mnt/jweb-ex-33d6a634/jail/var/tmp Je me casse toujours les dents sur mes EX2300, sur lesquels il n'y a pas assez de place pour faire des snapshots recovery. Un suspect est le /var/tmp, qui a un point de montage assez étrange (en sous-dossier du package J-Web). Est-ce que l'utilisation du shell FreeBSD est supportée pour y faire des choses au niveau de l'OS, comme par exemple modifier un fichier de démarrage pour changer un point de montage ? Y a t-il des docs en ce sens ? A quel endroit pourrait se trouver le montage du /var/tmp vers ce chemin bizarre ? Merci par avance pour vos idées. Sinon, il ne me restera plus qu'à attendre Vendredi pour poster une petite annonce en [BIZ] ;-) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Juniper EX2300 /var/tmp : no space left
Le 25/01/2024 à 21:44, Pierre Emeriaud a écrit : Et encore, maintenant y'a junos evo, où on abandonne complètement freebsd pour passer sur un os linux... M'ouais... Si je comprends bien, je me suis fait fourguer des pièces de musée avec ces EX2300, qui ont des hardware obsolètes pour faire tourner les versions actuelles de l'OS, et ne semblent pas supporter les versions futures ? Décidément, c'est ma fête tous les jours en ce moment :-D Et en plus, Juniper a été racheté par hpe, donc je retourne exactement là d'où je voulais me barrer :-D Entre autres parce qu'ils rachetaient n'importe quoi sans aucune cohérence dans les gammes :-D En plus de changer de nom, il faut aussi que je change de boulot :-) J'avais envisagé agriculteur :-) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Juniper EX2300 /var/tmp : no space left
Le jeu. 25 janv. 2024 à 15:24, ic a écrit : > > io, > > > On 25 Jan 2024, at 14:16, Toussaint OTTAVI wrote: > > > >> Parceque (comme d'autes), ils ont collé leur nom et "bricolé" leur OS > >> pour le faire rentrer dans du matériel sous-traité ou provenant d'un > >> rachat ? > > non plutôt depuis que le développement a déménagé en Inde… et leur qualité de > code réputée mondialement... > > > L'OS Juniper, et sa base FreeBSD, çà me semble quand même pas trop mauvais, > > non ? Sur un CPU qui ne met pas 16 minutes à booter, et avec 10 € de > > mémoire flash en plus, çà pourrait dépoter… > > > Aux dernières nouvelles pour des questions de drivers (entre autres), les > restes de FreeBSD chez Jun tournent dans une VM dans un Linux… Et encore, maintenant y'a junos evo, où on abandonne complètement freebsd pour passer sur un os linux... --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Juniper EX2300 /var/tmp : no space left
Le 25/01/2024 à 15:23, ic a écrit : Aux dernières nouvelles pour des questions de drivers (entre autres), les restes de FreeBSD chez Jun tournent dans une VM dans un Linux… :-o Vendredi, c'est demain ? Non ? --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Juniper EX2300 /var/tmp : no space left
io, > On 25 Jan 2024, at 14:16, Toussaint OTTAVI wrote: > >> Parceque (comme d'autes), ils ont collé leur nom et "bricolé" leur OS >> pour le faire rentrer dans du matériel sous-traité ou provenant d'un >> rachat ? non plutôt depuis que le développement a déménagé en Inde… et leur qualité de code réputée mondialement... > L'OS Juniper, et sa base FreeBSD, çà me semble quand même pas trop mauvais, > non ? Sur un CPU qui ne met pas 16 minutes à booter, et avec 10 € de mémoire > flash en plus, çà pourrait dépoter… Aux dernières nouvelles pour des questions de drivers (entre autres), les restes de FreeBSD chez Jun tournent dans une VM dans un Linux… ++ ic --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Juniper EX2300 /var/tmp : no space left
io, > On 25 Jan 2024, at 14:16, Toussaint OTTAVI wrote: > > Et sinon, en switch 24 / 48 ports qui supporte OpenWRT, ou toute autre > solution libre, il y aurait quelque chose de correct ? vu que tu ne précises pas la vitesse des ports, j’en profite pour coller ça : https://www.linkedin.com/pulse/debian-mellanox-100g-switch-pim-van-pelt-3pivf/ ++ ic --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Juniper EX2300 /var/tmp : no space left
Le 25/01/2024 à 14:16, Toussaint OTTAVI a écrit : Le 25/01/2024 à 11:17, Dominique Rousseau a écrit : Parceque (comme d'autes), ils ont collé leur nom et "bricolé" leur OS pour le faire rentrer dans du matériel sous-traité ou provenant d'un rachat ? Heu, non, çà, c'était hpe avant le rachat :-D Quoique, hpe ne bricole que le logo. 5 gammes de switches = 5 OS différents :-) Quand il n'y a pas deux interfaces différentes simultanément sur le même appareil :-) L'OS Juniper, et sa base FreeBSD, çà me semble quand même pas trop mauvais, non ? Sur un CPU qui ne met pas 16 minutes à booter, et avec 10 € de mémoire flash en plus, çà pourrait dépoter... -- Et sinon, en switch 24 / 48 ports qui supporte OpenWRT, ou toute autre solution libre, il y aurait quelque chose de correct ? --- Liste de diffusion du FRnOG http://www.frnog.org/ En tout cas c'est pas la base FreeBSD qui va rebuter HPE, leurs switches Commware 7 c'est déjà une base FreeBSD -- Erwan David --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Juniper EX2300 /var/tmp : no space left
Le 25/01/2024 à 11:17, Dominique Rousseau a écrit : Parceque (comme d'autes), ils ont collé leur nom et "bricolé" leur OS pour le faire rentrer dans du matériel sous-traité ou provenant d'un rachat ? Heu, non, çà, c'était hpe avant le rachat :-D Quoique, hpe ne bricole que le logo. 5 gammes de switches = 5 OS différents :-) Quand il n'y a pas deux interfaces différentes simultanément sur le même appareil :-) L'OS Juniper, et sa base FreeBSD, çà me semble quand même pas trop mauvais, non ? Sur un CPU qui ne met pas 16 minutes à booter, et avec 10 € de mémoire flash en plus, çà pourrait dépoter... -- Et sinon, en switch 24 / 48 ports qui supporte OpenWRT, ou toute autre solution libre, il y aurait quelque chose de correct ? --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Juniper EX2300 /var/tmp : no space left
Le Wed, Jan 24, 2024 at 09:48:29AM +0100, David Ponzone [david.ponz...@gmail.com] a écrit: > Juniper a fait des boulettes sur certains modèles, aucun expert de la marque > ici ne le niera: > -les switchs qui meurent quand ils se prennent des snmpwalk > -les switchs qui freezent pendant un court instant quand on insère un > module dans le port uplink (je sais, c???est documenté, mais c???est > quand même surprenant sur cette gamme de matos) > > Pourquoi ils en sont arrivés là, c???est une question intéressante > mais dont la réponse risque de nous échapper. Parceque (comme d'autes), ils ont collé leur nom et "bricolé" leur OS pour le faire rentrer dans du matériel sous-traité ou provenant d'un rachat ? -- Dominique Rousseau Neuronnexion, Prestataire Internet & Intranet 6 rue des Hautes cornes - 8 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Juniper EX2300 /var/tmp : no space left
Le 24/01/2024 à 09:48, David Ponzone a écrit : -les switchs qui meurent quand ils se prennent des snmpwalk :-o Et avec un ping6, je peux gagner un accès root, comme sous Windows ? :-D Pourquoi ils en sont arrivés là, c’est une question intéressante mais dont la réponse risque de nous échapper. Décidément, mon coté "chat noir" ne m'a pas trahi sur ce coup là ;-) Et dire qu'à l'origine, j'ai testé Juniper car je voulais quitter hpe, et que Juniper vient d'être racheté par... :-D --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Juniper EX2300 /var/tmp : no space left
Juniper a fait des boulettes sur certains modèles, aucun expert de la marque ici ne le niera: -les switchs qui meurent quand ils se prennent des snmpwalk -les switchs qui freezent pendant un court instant quand on insère un module dans le port uplink (je sais, c’est documenté, mais c’est quand même surprenant sur cette gamme de matos) Pourquoi ils en sont arrivés là, c’est une question intéressante mais dont la réponse risque de nous échapper. David > Le 24 janv. 2024 à 09:25, Toussaint OTTAVI a écrit : > > > Le 23/01/2024 à 17:35, Cyril LAVIER a écrit : >> Les EX2300 ne sont clairement pas du haut de gamme. En tant que switch >> edge/top of rack, c'est l'entrée de gamme chez Juniper. > > En fait, je n'ai pas besoin de plus. Il n'y a que du L2 dessus, une dizaine > de VLANs, et aucun des liens n'atteint le gigabit. > >> Pas pour rien que VChassis est soumis à licence et limité à 4 membres (au >> lieu de 10 pour les EX3400 ou EX4400). > > Dans mon cas, deux me suffisent (tolérance de panne basique LACP). Donc, le > choix des EX2300 me semblait pertinent. D'autant plus que les prédécesseurs > EX2200 en "refurb" m'avaient été recommandés ici... > >> Bien sûr, ça n'excuse pas le fait que le stockage local soit ridiculement >> petit comparé à la taille d'un package de firmware (y compris sur les QFX au >> final...). > > Et surtout, pas suffisant pour faire un snapshot recovery ! On se moque > souvent (assez gentiment) des marques "premier prix", pour des problèmes > moins critiques que çà, et pour des appareils qui, finalement, coûtent le > quart de celui-ci... > > > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Juniper EX2300 /var/tmp : no space left
Le 23/01/2024 à 17:35, Cyril LAVIER a écrit : Les EX2300 ne sont clairement pas du haut de gamme. En tant que switch edge/top of rack, c'est l'entrée de gamme chez Juniper. En fait, je n'ai pas besoin de plus. Il n'y a que du L2 dessus, une dizaine de VLANs, et aucun des liens n'atteint le gigabit. Pas pour rien que VChassis est soumis à licence et limité à 4 membres (au lieu de 10 pour les EX3400 ou EX4400). Dans mon cas, deux me suffisent (tolérance de panne basique LACP). Donc, le choix des EX2300 me semblait pertinent. D'autant plus que les prédécesseurs EX2200 en "refurb" m'avaient été recommandés ici... Bien sûr, ça n'excuse pas le fait que le stockage local soit ridiculement petit comparé à la taille d'un package de firmware (y compris sur les QFX au final...). Et surtout, pas suffisant pour faire un snapshot recovery ! On se moque souvent (assez gentiment) des marques "premier prix", pour des problèmes moins critiques que çà, et pour des appareils qui, finalement, coûtent le quart de celui-ci... --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Juniper EX2300 /var/tmp : no space left
Salut. Les EX2300 ne sont clairement pas du haut de gamme. En tant que switch edge/top of rack, c'est l'entrée de gamme chez Juniper. Pas pour rien que VChassis est soumis à licence et limité à 4 membres (au lieu de 10 pour les EX3400 ou EX4400). Les EX3400 sont le milieu de gamme et les EX4400 sont plus haut en gamme pour tout ce qui est edge/top of rack. J'ai des EX2300 et EX3400 en production, et j'fais passer aucune data sensible sur les EX2300, ils me servent de switchs pour du IPMI ou management interfaces. Mon switch de base dans ce cas est l'EX3400. Bien sûr, ça n'excuse pas le fait que le stockage local soit ridiculement petit comparé à la taille d'un package de firmware (y compris sur les QFX au final...). On Tue, 23 Jan 2024 at 03:57, Toussaint OTTAVI wrote: > > Le 22/01/2024 à 22:49, Jarod G. via frnog a écrit : > > Pour les majs je te conseille en premier temps de passer les commandes > > suivantes : > > > >> request system storage cleanup > >> clear log wtmp > >> request system snapshot delete previous > > > > Puis de pousser ton tgz de maj sur /tmp et pousser la commande > > d'upgrade avec no-validate et no-copy > > Merci pour les réponses. > > Concernant les mises à jour, oui, j'ai réussi à m'en tirer en appliquant > les différentes commandes de nettoyage, et en mettant mon package.tgz > dans /tmp (et pas dans /var/tmp). Du coup, çà passe. > > En revanche, là où je n'ai pas de solution, c'est pour faire un snapshot > en mode recovery : >request system snapshot recovery : > mkuzip: write(/var/tmp/.snap.22622/recovery.ufs.uzip): No space > left on device > > Si j'interprète bien le message d'erreur, ce n'est pas la place dans la > partition /oam qui manque pour stocker le snapshot, mais c'est l'espace > disque temporaire pour générer le fichier zip. Et là, je ne sais pas > comment lui dire d'utiliser autre chose que /var/tmp comme espace > temporaire. > > > Le 22/01/2024 à 20:06, Cyril LAVIER a écrit : > > Concernant ta question sur la clé USB, je dirais que techniquement, ça > > ne devrait pas gêner, mais quid de la survie de la clé USB, même si ça > > s'améliore, je trouve ça toujours trop peu fiable pour en laisser une > > à demeure. > > Entre laisser une clef USB à demeure et prendre le risque de péter le > fonctionnement parce que le disque est plein, mon choix est vite fait :-) > Ceci étant, j'ai bien compris comment monter une clef USB en tant que > stockage supplémentaire, par exemple pour y stocker mes .tgz. Mais je > n'ai pas compris comment monter cette clef à la place de /var/tmp, pour > que le système l'utilise pour ses propres fichiers temporaires... > > -- > Corollairement, pour un truc positionné assez haut en gamme, je trouve > quand même çà assez peu sérieux. Ce truc bat à ce jour, et de loin, le > temps passé en lab avant de pouvoir valider les tests de base ! Si je > mets çà en prod, et que je vais devoir serrer les fesses chaque fois que > j'ai une mise à jour à faire, autant installer une machine sous Windows > et faire un routeur avec :-D > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > -- Cyril Lavier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Juniper EX2300 /var/tmp : no space left
> Le 23 janv. 2024 à 10:42, Arnaud Launay a écrit : > > > Depuis, on est passés sur du Mikrotik et du FRR soft. Pas un ennui. Ça switch > à 40G, > et ça route à 10G (oui, petite bite, je sais) sans broncher, sur une caisse > 10 fois > moins chère qu'un Juniper et avec 16 fois de plus de ram et de cpu. > > Ça encaisse sans broncher les ± 925000 routes actuelles, avec plusieurs full > transit, > des peerings, etc. > J’ai déjà dit que le VSR de 6Wind, ça déchire sa race, et le support est à la hauteur ? :) Ah ben si je l’ai pas dit, je le dis :) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Juniper EX2300 /var/tmp : no space left
Le Tue, Jan 23, 2024 at 09:57:32AM +0100, Toussaint OTTAVI a écrit: > Corollairement, pour un truc positionné assez haut en gamme, je trouve quand > même çà assez peu sérieux. Ce truc bat à ce jour, et de loin, le temps passé > en lab avant de pouvoir valider les tests de base ! Si je mets çà en prod, > et que je vais devoir serrer les fesses chaque fois que j'ai une mise à jour > à faire, autant installer une machine sous Windows et faire un routeur avec > :-D T'inquiètes pas, la prochaine fois que tu voudras faire une mise à jour, il te dira que la cartouche d'encre bleue est vide à 70% et qu'il refuse de faire quoi que ce soit tant que tu ne l'auras pas changée. Plus sérieusement, le problème de stockage, que ce soit disque ou ram, est récurrent chez Juniper. On ne vit pas dans le même monde qu'eux. Quand je vois les MX5 d'il y a 10 ans qui avaient 2Go de ram et un processeur asthmatique... On aurait pu faire abstraction du proc, mais les 2Go de ram, c'est ce qui les a tué pour nous. Depuis, on est passés sur du Mikrotik et du FRR soft. Pas un ennui. Ça switch à 40G, et ça route à 10G (oui, petite bite, je sais) sans broncher, sur une caisse 10 fois moins chère qu'un Juniper et avec 16 fois de plus de ram et de cpu. Ça encaisse sans broncher les ± 925000 routes actuelles, avec plusieurs full transit, des peerings, etc. Le MX5 serait en PLS depuis longtemps. Arnaud. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Juniper EX2300 /var/tmp : no space left
Le 22/01/2024 à 22:49, Jarod G. via frnog a écrit : Pour les majs je te conseille en premier temps de passer les commandes suivantes : request system storage cleanup clear log wtmp request system snapshot delete previous Puis de pousser ton tgz de maj sur /tmp et pousser la commande d'upgrade avec no-validate et no-copy Merci pour les réponses. Concernant les mises à jour, oui, j'ai réussi à m'en tirer en appliquant les différentes commandes de nettoyage, et en mettant mon package.tgz dans /tmp (et pas dans /var/tmp). Du coup, çà passe. En revanche, là où je n'ai pas de solution, c'est pour faire un snapshot en mode recovery : request system snapshot recovery : mkuzip: write(/var/tmp/.snap.22622/recovery.ufs.uzip): No space left on device Si j'interprète bien le message d'erreur, ce n'est pas la place dans la partition /oam qui manque pour stocker le snapshot, mais c'est l'espace disque temporaire pour générer le fichier zip. Et là, je ne sais pas comment lui dire d'utiliser autre chose que /var/tmp comme espace temporaire. Le 22/01/2024 à 20:06, Cyril LAVIER a écrit : Concernant ta question sur la clé USB, je dirais que techniquement, ça ne devrait pas gêner, mais quid de la survie de la clé USB, même si ça s'améliore, je trouve ça toujours trop peu fiable pour en laisser une à demeure. Entre laisser une clef USB à demeure et prendre le risque de péter le fonctionnement parce que le disque est plein, mon choix est vite fait :-) Ceci étant, j'ai bien compris comment monter une clef USB en tant que stockage supplémentaire, par exemple pour y stocker mes .tgz. Mais je n'ai pas compris comment monter cette clef à la place de /var/tmp, pour que le système l'utilise pour ses propres fichiers temporaires... -- Corollairement, pour un truc positionné assez haut en gamme, je trouve quand même çà assez peu sérieux. Ce truc bat à ce jour, et de loin, le temps passé en lab avant de pouvoir valider les tests de base ! Si je mets çà en prod, et que je vais devoir serrer les fesses chaque fois que j'ai une mise à jour à faire, autant installer une machine sous Windows et faire un routeur avec :-D --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Juniper EX2300 /var/tmp : no space left
Salut, On a une blinde d'EX2300 et EX3400 (les deux ont le même soucis) à $job Il y a une KB à ce sujet : https://kb.juniper.net/InfoCenter/index?page=content=KB31198 Pour les majs je te conseille en premier temps de passer les commandes suivantes : request system storage cleanup clear log wtmp request system snapshot delete previous (s'assurer également qu'il y a pas des snapshots qui traînent) Puis de pousser ton tgz de maj sur /tmp et pousser la commande d'upgrade avec no-validate et no-copy Si ça passe pas car toujours pas assez de place, tu peux faire un file list /packages/sets/ detail et vérifier qu'il y a que la version "active" des paquets JunOS qui existent. J'ai toujours nettoyé manuellement mais à priori y a des commandes fait pour dans la KB plus haut, je t'invite à y jeter un oeil. À défaut si t'es vraiment désespéré : https://kb.juniper.net/InfoCenter/index?page=content=KB31265 A+ Jarod G. Le 22/01/2024 à 16:32, Toussaint OTTAVI a écrit : Salut les pros de Juniper, J'ai deux EX2300 en lab, avec lesquels je me casse les dents depuis un moment, au point que je n'ai nulle confiance à les mettre en prod ! Les problèmes, assez récurrents, tournent toujours autour de l'espace disponible dans /var/tmp, et çà bloque la plupart des opérations de maintenance de base. Bien entendu, les méthodes documentées de nettoyage ne suffisent absolument pas (request system storage cleanup, request system snapshot delete snap*, start shell command "pkg setop rm previous" , etc...). Par exemple, il est impossible de faire une mise à jour JunOS en stockant le firmware .tgz dans /var/tmp, comme c'est indiqué dans à peu près toutes les docs que j'ai pu lire. Je m'en tire en mettant mon .tgz sur clef USB. J'ai découvert également qu'il y avait un autre point de montage tmpfs sur lequel il y a (un peu) plus de place : /tmp En revanche, un autre truc plus problématique qui coince, c'est la création des snapshots recovery (request system snapshot recovery) : mkuzip: write(/var/tmp/.snap.22622/recovery.ufs.uzip): No space left on device Donc, si je comprends bien, ce n'est pas l'espace sur la partition /oam qui manque pour stocker le snapshot final, mais plutôt l'espace temporaire pour créer celui-ci. Et là, je ne sais pas comment lui dire d'utiliser /tmp au lieu de /var/tmp ! En regardant les points de montage d'un peu plus près : df -h | grep /tmp tmpfs 826M 16K 826M 0% /.mount/tmp /var/tmp 1.3G 544M 712M 43% /.mount/packages/mnt/jweb-ex-33d6a634/jail/var/tmp Donc, je ne connais rien à FreeBSD ni aux jails, mais on dirait que le package j-web a "détourné" mon /var/tmp ! Questions : - Puis-je monter mon /var/tmp au même endroit que /tmp pour qu'il y ait plus de place ? - Quelqu'un a t-il trouvé le moyen de souder 2 Go de flash supplémentaires ? Peut-on laisser une clef USB à demeure, et monter /var/tmp de façon permanente dessus ? Parce que là, vu le prix de base des engins, comment dire... Cà me donnerait presque envie de les re-flasher sous OpenWRT :-D --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Juniper EX2300 /var/tmp : no space left
Salut. Concernant les mises à jour, t'as essayé de passer par un HTTP/FTP local ? Les quelques EX2300 que j'ai en prod, je les ai tous mis à jour avec un repo HTTP local que j'ai mis en place pour me faciliter la vie. Concernant ta question sur la clé USB, je dirais que techniquement, ça ne devrait pas gêner, mais quid de la survie de la clé USB, même si ça s'améliore, je trouve ça toujours trop peu fiable pour en laisser une à demeure. On Mon, 22 Jan 2024 at 10:32, Toussaint OTTAVI wrote: > Salut les pros de Juniper, > > J'ai deux EX2300 en lab, avec lesquels je me casse les dents depuis un > moment, au point que je n'ai nulle confiance à les mettre en prod ! Les > problèmes, assez récurrents, tournent toujours autour de l'espace > disponible dans /var/tmp, et çà bloque la plupart des opérations de > maintenance de base. > > Bien entendu, les méthodes documentées de nettoyage ne suffisent > absolument pas (request system storage cleanup, request system snapshot > delete snap*, start shell command "pkg setop rm previous" , etc...). > > Par exemple, il est impossible de faire une mise à jour JunOS en > stockant le firmware .tgz dans /var/tmp, comme c'est indiqué dans à peu > près toutes les docs que j'ai pu lire. Je m'en tire en mettant mon .tgz > sur clef USB. J'ai découvert également qu'il y avait un autre point de > montage tmpfs sur lequel il y a (un peu) plus de place : /tmp > > En revanche, un autre truc plus problématique qui coince, c'est la > création des snapshots recovery (request system snapshot recovery) : >mkuzip: write(/var/tmp/.snap.22622/recovery.ufs.uzip): No space left > on device > > Donc, si je comprends bien, ce n'est pas l'espace sur la partition /oam > qui manque pour stocker le snapshot final, mais plutôt l'espace > temporaire pour créer celui-ci. Et là, je ne sais pas comment lui dire > d'utiliser /tmp au lieu de /var/tmp ! > > En regardant les points de montage d'un peu plus près : > df -h | grep /tmp >tmpfs 826M 16K826M 0%/.mount/tmp >/var/tmp 1.3G544M712M43% > /.mount/packages/mnt/jweb-ex-33d6a634/jail/var/tmp > > Donc, je ne connais rien à FreeBSD ni aux jails, mais on dirait que le > package j-web a "détourné" mon /var/tmp ! > > Questions : > - Puis-je monter mon /var/tmp au même endroit que /tmp pour qu'il y ait > plus de place ? > - Quelqu'un a t-il trouvé le moyen de souder 2 Go de flash > supplémentaires ? Peut-on laisser une clef USB à demeure, et monter > /var/tmp de façon permanente dessus ? > > Parce que là, vu le prix de base des engins, comment dire... Cà me > donnerait presque envie de les re-flasher sous OpenWRT :-D > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > -- Cyril Lavier --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] Juniper EX2300 /var/tmp : no space left
Salut les pros de Juniper, J'ai deux EX2300 en lab, avec lesquels je me casse les dents depuis un moment, au point que je n'ai nulle confiance à les mettre en prod ! Les problèmes, assez récurrents, tournent toujours autour de l'espace disponible dans /var/tmp, et çà bloque la plupart des opérations de maintenance de base. Bien entendu, les méthodes documentées de nettoyage ne suffisent absolument pas (request system storage cleanup, request system snapshot delete snap*, start shell command "pkg setop rm previous" , etc...). Par exemple, il est impossible de faire une mise à jour JunOS en stockant le firmware .tgz dans /var/tmp, comme c'est indiqué dans à peu près toutes les docs que j'ai pu lire. Je m'en tire en mettant mon .tgz sur clef USB. J'ai découvert également qu'il y avait un autre point de montage tmpfs sur lequel il y a (un peu) plus de place : /tmp En revanche, un autre truc plus problématique qui coince, c'est la création des snapshots recovery (request system snapshot recovery) : mkuzip: write(/var/tmp/.snap.22622/recovery.ufs.uzip): No space left on device Donc, si je comprends bien, ce n'est pas l'espace sur la partition /oam qui manque pour stocker le snapshot final, mais plutôt l'espace temporaire pour créer celui-ci. Et là, je ne sais pas comment lui dire d'utiliser /tmp au lieu de /var/tmp ! En regardant les points de montage d'un peu plus près : df -h | grep /tmp tmpfs 826M 16K 826M 0% /.mount/tmp /var/tmp 1.3G 544M 712M 43% /.mount/packages/mnt/jweb-ex-33d6a634/jail/var/tmp Donc, je ne connais rien à FreeBSD ni aux jails, mais on dirait que le package j-web a "détourné" mon /var/tmp ! Questions : - Puis-je monter mon /var/tmp au même endroit que /tmp pour qu'il y ait plus de place ? - Quelqu'un a t-il trouvé le moyen de souder 2 Go de flash supplémentaires ? Peut-on laisser une clef USB à demeure, et monter /var/tmp de façon permanente dessus ? Parce que là, vu le prix de base des engins, comment dire... Cà me donnerait presque envie de les re-flasher sous OpenWRT :-D --- Liste de diffusion du FRnOG http://www.frnog.org/
