@smortex@mamot.fr
@smortex@mamot.fr avatar

smortex

@smortex@mamot.fr

#Hacker, #FLOSS Mercenary, #FreeBSD developer (romain@), #BOFH, love stuff from the 70's (e.g. #UNIX, Japanese hard-rock) and #Ruby. #Puppet; #Choria; #Riemann

This profile is from a federated server and may be incomplete. Browse more on the original instance.

smortex, to random French
@smortex@mamot.fr avatar

Vous connaissez un logiciel de d' avec le support de méta-données structurés et référençables ?

Dans une collection de photos de requins, on veut identifier un même individu qui apparaît sur plusieurs clichés, rattacher des données variées (date, lieu, profondeur, taille, sexe, gestante, etc.) tout ça pour étudier leurs déplacements et modes de vie en filtrant cette photothèque par lieu, date, sexe, sur un individu en particulier, etc.

:boost_ok: Merci de partager !

cero, to random
@cero@iceshrimp.social avatar
smortex,
@smortex@mamot.fr avatar

@cero looks like an OVH datacenter, not a Hetzner one…

rodolphe, to FreeBSD

I really like #FreeBSD because it's simple, stable and there's a lot of nice features. However, there is two things that I find quite annoying.

  1. The version system. I seriously have no idea how this thing works. Why is the results of the freebsd-version and sysctl -n kern.osrelease commands different? Why updating my jails doesn't seems to actually update them? And why the hell freebsd-version is sometimes able to display 2 different versions at the same time?

  2. The rc.d system. I have a weird bug with an executable that runs just fines from CLI, but the exact same command doesn't work at all when started with rc.d. Also, the service xxx status command just reported me a service as not running while it was, in fact, running just well. Plus, writing a service script is a PITA. I'm not a big fan of systemd, but let's face it: a lot of things really needed to change and they did quite a good job about it.

smortex,
@smortex@mamot.fr avatar

@rodolphe Hey 👋

  1. Check the freebsd-version man page, it report userland version by default, which may be different from the kernel version (e.g. an update fix userland issue but the kernel is the same) and the installed kernel version (i.e. you installed a new kernel but have not rebooted yet).

sysctl kern.osrelease should match freebsd-version -r.

  1. That's usually caused by the program depending on some environment variables. Run it with env -i prog to see if it is the case.
smortex,
@smortex@mamot.fr avatar

@rodolphe 1. Weird

I run FreeBSD 14 and here is the output of these commands on an up-to-date system (conform to my expectations):

romain@agrajag ~ % freebsd-version -kru
14.0-RELEASE-p3
14.0-RELEASE-p3
14.0-RELEASE-p4
romain@agrajag ~ % sysctl kern.osrelease
kern.osrelease: 14.0-RELEASE-p3

smortex,
@smortex@mamot.fr avatar

@rodolphe 2. Assigning variables in the prestart function looks… unusual, I am not sure this would work. Also I am not sure that tweaking rc_flags is the way to go.

I would update command_args instead of rc_args, and do this outside of the prestart function (just remove the function), and keep the variable assignments where they are.

To see what is going on, you can run sh -x /usr/local/etc/rc.d/acmed start and you will probably see what is not going as you expect in the last lines 😉

smortex,
@smortex@mamot.fr avatar

@rodolphe kernel (-k) and running (-r) will be different after updating and before reboot.

kernel (-k) / running (-r) and userland (-u) can be different if the last update was fixing userland tools only.

Here, -p4 fix ssh issues (FreeBSD-SA-23:19 / CVE-2023-48795), this is userland only, and the update does not touch the kernel. So the kernel is still the one of 14.0-RELEASE-p3.

The previous update fixed nfs issues (FreeBSD-SA-23:18 / CVE-2023-6660) and required a new kernel.

smortex,
@smortex@mamot.fr avatar

@rodolphe Ohh… I see this at the end of the function:

 run_rc_command xyzzy   
 return 0  

This is probably something you can do and that will help. That's not very nice IMHO, but basically you want to abort the "usual" flow and actually run the command from there…

I bet this guide need some love, and would rather recommend checking other services you have on your system to see how they deal with similar needs.

prestart is more intended for this kind of things:
https://cgit.freebsd.org/ports/tree/sysutils/puppetserver8/files/puppetserver.in

smortex,
@smortex@mamot.fr avatar

@rodolphe procstat(1) to the rescue maybe?

You can inspect various aspect of the process with it, environment and cwd would be my first checks to see how they differ and if it can have an impact on the program.

Also, closing stdin/stdout/stderr may induce a different behavior with some programs.

Last but not least, you mention jails. They may prevent SYSV IPC from working by default which may be required by some applications.

Good luck!

smortex, to random
@smortex@mamot.fr avatar

I was wondering about how TLS versions usage was evolving. We log some TLS info with #syslog_ng so we can do some digging in #OpenSearch to find out.

Since February 2023, $WORK see a rather constant 96% of HTTPS traffic over TLS 1.3, the rest being TLS 1.2.

Regarding outgoing mail, we experienced a jump from ~30% to ~85% of TLS 1.3 in November 2022 but mostly caused by a customer switching from its ISP to another provider mail services.

The ISP itself started to support TLS 1.3 in April 2023.

A bar graph showing the evolution of the ratio of TLS versions for outgoing e-mail at $WORK.
A bar graph showing the remote hostname for outgoing e-mail at $WORK. "promx1.vini.pf" and "promx2.vini.pf" disappear while "mx-mibc-fr-09.mailinblack.com" replace it in November 2022.
The previous last 2 bar graph but only showing the promx1 / promx2 remote hosts. Traffic to these hosts drop in November 2022, and in April 2023 the remaining traffic switch from TLS 1.2 to TLS 1.3.

feld, to random
@feld@bikeshed.party avatar

deleted_by_author

  • Loading...
  • smortex,
    @smortex@mamot.fr avatar

    @feld Bacula. Not user friendly, far from trivial to deploy, but predictable and consistent in its behavior, and I hate surprises… particularly those related to backups!

    smortex, to random
    @smortex@mamot.fr avatar

    🇬🇧 Last week took place Makatea Vertical Adventure. I will post some pictures.

    🇫🇷 La semaine dernière a eu lieu Makatea Vertical Adventure. Je vais poster quelques photos.

    🇵🇫 Te hepetoma i ma'iri, ua tupu Makatea Vertical Adventure. E fa'a'ite au ta'u mau hoho'a

    #MVA2023 #Makatea

    Photograph of the boad from the dock of Makatea.
    Photograph of the dock of Makatea from a viewpoint.

    smortex,
    @smortex@mamot.fr avatar
    smortex,
    @smortex@mamot.fr avatar

    @krisfreedain Yeah! It's quite a trip (9h of boat from , but it was a fast boat, and over night so we could sleep), but the island is gorgeous and does not look like the surrounding atolls from Tuamotu.

    il mostly about climbing, via ferrata, abseiling and zip lines. Once everything is packed, not much to think about: just enjoy the site 😉

    I'll don't have a lot of pictures but I will post more in the next days, the fediverse is under represented in French Polynesia!

    masukomi, to random
    @masukomi@connectified.com avatar

    A on mystery in 3 images. Solution in 🧵

    controller has 2 actions, which i've called first_action and second_action just to distinguish them.

    Rails will ALWAYS send you to first_action even when the route, and the action_name are second_action.

    images: controller, debugger at breakpoint, routes

    I stared at this for SO long before i figured it out while rubber-ducking it.

    a screenshot of the debugger stopped at a breakpoint.
    a screenshot of the routes.

    smortex,
    @smortex@mamot.fr avatar

    @masukomi

    For the record, on your screenshot it seems your editor shows blue waves on the line bellow "before_action" and under "def". Does this correspond to some kind of warning?

    pb, to random French
    @pb@mast.eu.org avatar

    Google Cloud Platform, région France (europe-west9) : inondation. ETA inconnu. https://status.cloud.google.com/incidents/dS9p

    smortex,
    @smortex@mamot.fr avatar
  • All
  • Subscribed
  • Moderated
  • Favorites
  • megavids
  • thenastyranch
  • rosin
  • GTA5RPClips
  • osvaldo12
  • love
  • Youngstown
  • slotface
  • khanakhh
  • everett
  • kavyap
  • mdbf
  • DreamBathrooms
  • ngwrru68w68
  • provamag3
  • magazineikmin
  • InstantRegret
  • normalnudes
  • tacticalgear
  • cubers
  • ethstaker
  • modclub
  • cisconetworking
  • Durango
  • anitta
  • Leos
  • tester
  • JUstTest
  • All magazines