Re: [FRnOG] [TECH] Juniper EX2300 /var/tmp : no space left

2024-01-22 Par sujet Jarod G. via frnog 

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] demande d’info sur des serveur basée sur Strasbourg / Revendeur

2023-09-05 Par sujet Jarod G. via frnog 

Hello,

j'en profite de ce sujet : y a du monde qui commence à s'installer au DC 
d'Euclyde à Illkirch ? (https://www.euclyde.com/dc7strasbourg/)


Car bon, quand on voit l'état du DC de Cogent à Schiltigheim et le 
Netcenter SFR... Perso ça me donne pas envie de poser du matos...


Jarod G.

Le 05/09/2023 à 09:07, Daniel via frnog a écrit :

Bonjour

contact ARN https://arn-fai.net/fr

Le 05/09/2023 à 09:02, c czh a écrit :
Bonjour, aujourd’hui je vient vers vous car je recherche de 
l’hébergement

sur Strasbourg, je recherche un serveur dédier sur des infrastructures
basée sur Strasbourg, si possible du 1G, pas du OVH des hébergeur 
local, ou
je cherche 2U pas trop chère pour le lancement d’une petit infra pour 
une

association, ou un VPS pour crée un routeur dessus, Merci la team FRnOG
Cordialement, Chris

---
Liste de diffusion du FRnOG
http://www.frnog.org/





---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] MOBILE DEVICE MANAGEMENT POUR GESTION DE FLOTTE GSM

2022-10-17 Par sujet Jarod G. via frnog 

Salut,

tout dépend les devices que t'as derrière les lignes, à $job on a JAMF 
pour tout ce qui est Apple (qui marche très bien mais c'est assez long à 
prendre en main correctement) par exemple et la solution VMWare (dont 
j'ai oublié le nom) pour le parc Android (qu'on exploite pas encore, ça 
va être en test soon), mais je sais que y a MobileIron qui existe et qui 
fonctionne avec les deux.


Jarod G.

On 17/10/2022 18:01, Lionel RIVIERE wrote:

Bonjour à tous,

Je suis à la recherche d'un produit de Mobile Device Management , j'avais cela 
au catalogue SFR y a 10 ans
Mais depuis le marché à du évoluer ...

Certains d'entre vous utilise surement cela, avez-vous des sociétés a me 
recommander ?

Pour de la gestion de flotte jusqu'à 200 lignes a peu prés

Merci d'avance


L.RIVIERE

---
Liste de diffusion du FRnOG
http://www.frnog.org/



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Problème d'accès à une partie d'un site web

2022-06-21 Par sujet Jarod G. via frnog 

Salut,

La requête vers la seconde URL ne renvoi rien ?
Également le classique, ton client a testé sur un autre poste que le 
siens ? Car si il a utilisé le même portable entre site 1 et 2 c'est 
ptet lié.
Si sur un deuxième poste ça passe pas, voir si avec un poste "vierge" 
(sans AV, softs métiers à la con, etc.) ça passe ou non.


Car si tu arrive à y accéder en remote sur le site du client, imo c'est 
sur le poste le soucis.


Jarod


On 21/06/2022 20:36, David Ponzone wrote:

J’ai un problème assez étrange, et je cherche des éléments de réponse.

Un client peut accéder à:

https://www.bca.fr
Mais pas à:
https://www.bca.fr/reparateur-web/login.action 


Alors que la seconde URL est parfaitement joignable pour moi (donc même AS que 
mon client) ou depuis Bouygues FTTH ou depuis Orange Mobile.
Plus délicat: connecté en VPN SSL pour accéder au site depuis la même IP 
publique que mon client: ça marche.

Le client ne peut pas non plus accéder à la seconde URL depuis un site chez SFR.

Le site www.bca.fr  est chez OBS, et semble être derrière 
un BigIP (si j’en crois la réponse du serveur HTTP).

J’ai donc tendance à penser que c’est le BigIP qui va pas bien, ou alors une 
merdouille de MTU (d’ici à ce que le BigIP casse le PMTU Discovery, il n’y a 
qu’un pas).

Je cherche donc d’autres personnes qui auraient une impossibilité d’accès à la 
seconde URL.
Ca me permettrait de confirmer que ça vient pas de moi et SFR, et d’entamer les 
démarches pour établir un contact avec les gens qui gèrent le BigIP en 
question...

Merci

David Ponzone


---
Liste de diffusion du FRnOG
http://www.frnog.org/



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Statping-ng, WTF....

2022-05-17 Par sujet Jarod G. via frnog 

Salut,

Les deux, de mémoire la db n'est jamais vidée automatiquement et sqlite 
quand y a trop de records ça patine sévère.


On 17/05/2022 17:39, David Ponzone wrote:

Je suis le seul à avoir des soucis avec statping-ng ?
Quelques monitoring en place (genre 3 ou 4, toutes les secondes ou 5 sec), et 
au bout de quelques jours/semaines, la DB fait 200Mo, et les perfs de 
l’interface web deviennent anémiques à la limite de l’inutilisable. Non 
vraiment inutilisable en fait.
Il y avait déjà ce souci sur l’ancien statping.
Evidemment remettre à zéro la DB règle problème, mais j’ai pas trouvé de 
commande pour purger la DB de ce qui est plus ancien.

Limite de sqlite ou problème inhérent au code de statping-ng ?

Merci


---
Liste de diffusion du FRnOG
http://www.frnog.org/



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Outlook / MS smtp server sans reverse

2021-10-22 Par sujet Jarod G. via frnog 
Salut,

Oui c'est toujours une bonne pratique, juste que MS n'a jamais été bon élève en 
mail...

Jarod G. 

Le 22 octobre 2021 18:02:19 GMT+02:00, Laurent-Charles FABRE 
 a écrit :
>Bonjour la liste,
>
>mail à l'attention des SMTP admin
>
>MS nous envoie des mails via un range IP sans DNS inverse. (52.101.62/24)
>
>Est ce une bonne pratique révolue que de demander un résolution inverse
>valide sur un outbound SMTP ?
>
>Si je souhaite conserver ce garde fou basique, la seule solution est elle
>de whitelister tout le bloc MS 52.96/16 ?
>(whitelist sur le check reverse uniquement, je précise :-)
>
>Je passe le fait que les host passés dans le helo SMTP résolve en 127.0.0.1
>(ex. na01-obe.outbound.protection.outlook.com)
>Ca on s'en arrange ;-)
>
>Merci de vos conseils avisés.
>
>Laurent-Charles FABRE
>
>---
>Liste de diffusion du FRnOG
>http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] libreNMS

2021-10-20 Par sujet Jarod G. via frnog 
J'ai du mal à comprendre pourquoi c'est pas en stable par défaut, je 
sais que git pull master au lieu de checkout des tags stables c'est à la 
mode mais quand même...


On 20/10/2021 14:08, Guillaume Tournat via frnog wrote:
pour ne pas être embêté, il vaut mieux passer sur le canal "stable", 
en mettant dans config.php :


$config['update_channel'] = 'release';


au lieu de :
$config['update_channel'] = 'master';


Le 20/10/2021 à 12:58, Paul Caranton a écrit :

Bonjour,

Même problème ici, mais pour seulement un device.

Du coup, on pensait que ça venait du device en question.

Merci pour l'info !

Et oui, on est en daily update activé ici...

Paul

Le 20/10/2021 à 12:55, Mickael Monsieur a écrit :

Bonjour,

Qui d’autre a vu passer le bug de libreNMS de cette nuit ?

Nous on a eu des Device indiqués comme redémarres alors qu’ils ne 
l’ont pas été, puis toute la nuit / matinée leur uptime dans 
librenms était farfelu.


On a forcé une mise à jour ce matin et on a reçu les Recover dans la 
foulée…


Est ce que vous utilisez les daily update? J’ai vu qu’il est 
possible de passer en monthly, peut être à envisager ? Voir 
désactiver l’auto update totalement …


Mickael


---
Liste de diffusion du FRnOG
http://www.frnog.org/



---
Liste de diffusion du FRnOG
http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Urgent Détection de brouilleur

2021-03-21 Par sujet Jarod G. via frnog 
Hello,

Tu peut tenter d'envoyer un message à l'ANFR :
https://www.anfr.fr/fr/contact/poser-une-question/brouillage/

Le 21/03/2021 à 20:22, Kamel Moudachirou a écrit :
> Bonjour 
> 
> Depuis quelques semaines nous sommes confrontés à une forte perturbation du 
> wifi et du GSM 
> 
> Certains de nos matériels ne se connectent plus au wifi ce qui handicape 
> l’activité 
> 
> Je recherche des personnes spécialisée pour nous aider à détecter l’origine 
> de la perturbation 
> 
> Je vous remercie d’avance pour vos conseils 
> 
> Cordialement 
> 
> Envoyé de mon iPhone
> Kamel Moudachirou 
> 0698085658
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
> 

-- 
GPG : 71E5 89D2 ADA9 F401 56CE 4374 B11B 7C56 F111 C320



OpenPGP_signature
Description: OpenPGP digital signature

Re: [FRnOG] [MISC] SBG1 : Nouvel incendie chez OVH ce soir

2021-03-19 Par sujet Jarod G. via frnog 
Encore plus si celles-ci étaient connectées à rien...
Par contre apparemment pas de feu, vraiment ?

"Update March,19 9:30pm
The batteries were in unused room, not used, not connected. We didn’t
have the fire, but we had lot of smoke. The situation is under control
now. Everybody is safe.

We stop the operation in SBG for this night. We will take the decision
tomorrow."

https://twitter.com/olesovhcom/status/1373008716484726785

Le 19/03/2021 à 21:31, Jarod G. via frnog a écrit :
> Oles avait publié sur le sujet justement :
> 
> "Update March,15 9pm
> 
> We had the smoke in an unused room in SBG1. We shutdown SBG1+SBG4 & we
> called the firefighters to identify the root cause. The firefighter
> stopped the smoke which came from the batteries that we don’t use. More
> info tomorrow. We stop the operation this night."
> 
> https://twitter.com/olesovhcom/status/1373001710801653767
> 
> La question étant, pourquoi ces batteries auraient pris feu si elles
> étaient "inutilisées" ?
> 
> Le 19/03/2021 à 21:28, Philippe ASTIER via frnog a écrit :
>> Incroyable.
>> Je cite : "Le sinistre aurait touché 300 batteries de 25 kg sur le data 
>> Center SBG1. « 
>>
>> Beaucoup moins d’impact et incendie maîtrisé, c’est pour ça que j’ai mis 
>> MISC.
>>
>>
>> https://www.dna.fr/faits-divers-justice/2021/03/19/nouvel-incendie-chez-ovh 
>> <https://www.dna.fr/faits-divers-justice/2021/03/19/nouvel-incendie-chez-ovh>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
> 

-- 
GPG : 71E5 89D2 ADA9 F401 56CE 4374 B11B 7C56 F111 C320



OpenPGP_signature
Description: OpenPGP digital signature

Re: [FRnOG] [MISC] SBG1 : Nouvel incendie chez OVH ce soir

2021-03-19 Par sujet Jarod G. via frnog 
Oles avait publié sur le sujet justement :

"Update March,15 9pm

We had the smoke in an unused room in SBG1. We shutdown SBG1+SBG4 & we
called the firefighters to identify the root cause. The firefighter
stopped the smoke which came from the batteries that we don’t use. More
info tomorrow. We stop the operation this night."

https://twitter.com/olesovhcom/status/1373001710801653767

La question étant, pourquoi ces batteries auraient pris feu si elles
étaient "inutilisées" ?

Le 19/03/2021 à 21:28, Philippe ASTIER via frnog a écrit :
> Incroyable.
> Je cite : "Le sinistre aurait touché 300 batteries de 25 kg sur le data 
> Center SBG1. « 
> 
> Beaucoup moins d’impact et incendie maîtrisé, c’est pour ça que j’ai mis MISC.
> 
> 
> https://www.dna.fr/faits-divers-justice/2021/03/19/nouvel-incendie-chez-ovh 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
> 

-- 
GPG : 71E5 89D2 ADA9 F401 56CE 4374 B11B 7C56 F111 C320



OpenPGP_signature
Description: OpenPGP digital signature

Re: [FRnOG] [TECH] 62.4.64.0/19 (EUnet) routé chez NTT au lieu de Zayo ?!

2021-03-18 Par sujet Jarod G. via frnog 

Hello,

J'ai lancé une mesure avec une centaine de sondes atlas vers 62.4.71.65,

dispo ici https://atlas.ripe.net/measurements/29329981/


Jarod G.

On 18/03/2021 13:51, David Touitou wrote:

M'en parle pas.
Quand ça veut pas...

C'est : 62.4.71.64/27.


Sympa comme préfixe :)



Le 18 mars 2021 à 13:43, David Touitou  a écrit :


J'ai perdu l'accès à un de mes subnets (62.4.74/27).

62.4.71.64/0, désolé.


---
Liste de diffusion du FRnOG
http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/


OpenPGP_0xB11B7C56F111C320.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Re: [FRnOG] [TECH] OVH WHOIS information leak ?

2021-03-12 Par sujet Jarod G. via frnog 
Hello,

RAS sur les quelques domaines que je supervise (.me .eu .ovh .com)

Jarod G.

Le 12/03/2021 à 14:44, Philippe ASTIER via frnog a écrit :
> Salut à tous,
> 
> J’ai plusieurs domaines hébergés chez OVH (mais pas tous) qui se sont mis à 
> révéler mes coordonnées : adresse physique, numéro de téléphone, etc… bien 
> que le masquage soit toujours bien actif sur la console client.
> 
> Ca a l’air concomitant avec l’incident de SBG.
> 
> Vous voyez la même chose ?
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
> 

-- 
GPG : 71E5 89D2 ADA9 F401 56CE 4374 B11B 7C56 F111 C320



OpenPGP_signature
Description: OpenPGP digital signature