[sf-lug] Ubuntu zsys?

Alan Swithenbank alans at cuervo.stanford.edu
Wed Jan 12 10:43:03 PST 2022


Thanks! I'll dig in a bit deeper and see what needs to be
done about zsys.

Alan


On Wed, 12 Jan 2022, Michael Paoli wrote:

> Well ... I've certainly done a far bit with ZFS ... but
> not on Ubuntu and not so recently (though still using it ...
> just not so actively mucking about with it).
>
> And don't have experience with Ubuntu's Zsys ... as far as I can
> easily tell from some reading, this is Ubuntu's own thing (some
> downstreams may (have) pick(ed) it up - but head of the beast seems
> to be Ubuntu) to have a "helper" interface to ZFS and, as far as I can
> tell, is still also considered - even by Ubuntu - as "experimental".
> I'd also guestimate, if Ubuntu's dependencies are properly set up,
> it's likely feasible to rip that software out ... though how deep one
> may need go in reverse dependencies thereof ... who knows.
> E.g. if Ubuntu makes Desktop Environment (DE) mandatory or
> the like (e.g. for non-Server), and makes that depend upon some
> GUI file manager and makes that depend upon Zsys ... uhm, yeah,
> that.  But I'm guestimating it's probably not that bad to rip it
> out ... as Ubuntu-Server uses the same repos ... as does the
> other *buntus too, e.g. Kubuntu, Lubuntu, Xubuntu, ...
> So, they're all really just the same distro ... just different default
> set of packages installed and slightly different configurations thereof
> (e.g. I recall doing a detailed comparison once-upon-a-time between
> a pair of *buntus - only differences were packages installed by default,
> and some configuration files (but did include some core ones, e.g. like
> /etc/passwd having some different default user(s) - so not just config
> files for differing package sets, but at least some more common files
> too)).  Anyway, if Ubuntu-Server doesn't install by default or require
> the Zsys stuff and it can be removed (while still keeping ZFS), likely
> it can be removed from the other *butnus too,
> probably just a question/matter of what else needs (or should) be
> removed along with such removal of Zsys.
>
> Anyway, most of their documentation reads approximately ...
> about bare skeleton man pages which mostly reference same
> small set thereof ... source ... README ...
> "Link to blog posts until we have an internal documentation" ...
> bloggy bits:
> https://didrocks.fr/2020/05/21/zfs-focus-on-ubuntu-20.04-lts-whats-new/
> Anyway, if one is going to use ZSys, I might advise:
> remember, "experimental".
> And, probably keep a watch on the reported bugs ... yeah,
> those also topped search results presently without even
> trying to specifically look for problems/issues/bugs.
>
> Anyway, ... might be interesting to experiment/"play" with,
> but whether or not it ends up being of much/any consequence and
> sticking around or setting any particular growth/direction trends,
> I think that's still very much yet to be seen.
>
> So, anyway, my observations/guestimations on it thus far,
> and thus far no hands-on with ZSys.
>
>> From: "Alan Swithenbank" <alans at cuervo.stanford.edu>
>> Subject: [sf-lug] Ubuntu zsys?
>> Date: Wed, 12 Jan 2022 00:41:29 +0000 (UTC)
>
>> Hi,
>> 
>> Anyone had any encounters with Ubuntu zsys? I'm putting
>> together up a new box, and planned to set up zfs (been
>> using it). But, it sounds like Canonical has decided it
>> will install zsys by default now if you install zfs. The
>> fact that documentation mentions black-magic and repeated
>> tries to make it through their choosen communications
>> framework (gRPC) is a bit disconcerting. Not that Canonical
>> doing something that doesn't work well is too surprising these
>> days...;^) But, if anyone has any thoughts, I'd be happy to
>> hear them.
>> 
>> thanks!
>> 
>> Alan Swithenbank (waterdog)
>> 
>> PS, here's what is actually said:
>> 
>> "the unix socket which activates on demand zsysd is using SO_PEERCRED to 
>> pass credentials (who/when) and with some (black magic) wizardry and
>> multiple attempts, we were able to make it work over gRPC, the 
>> communication
>> RPC framework we are using. As this whole combination was not really
>> documented anywhere on the Internet, it may be useful to document that in
>> a more technical blog post in the future."
>



More information about the sf-lug mailing list