>>> WHICH ONE OF THESE *%*( FILES IS THE ONE I NEED TO EDIT TO GET SSH
>>> WORKING AGAIN? ALL OF THEM? $*%)()!!!
>> This, of course, is not an issue if the admin really understands the
>> setup - but it will, sooner or later, become an issue if not.
> neither of you need to use it.
That could be s
Sun, Nov 22, 2020 at 02:21:24PM -0500, Mouse:
> > [...], but I DO like that it eases and therefore promotes IaC,
> > programmatic configuration.
>
> That's exactly what I don't like about it. It leads, fairly directly,
> to admins who don't really understand their systems. This is fine
I think
> I am sympathetic, but a directory of fragments is very thin syntactic
> sugar over having it all in a file.
True...and false. It's not all that thin, because...
> It does mean that "update this file if it hasn't changed" is likely
> to work on each fragment, rather than failing on something wh
Mouse writes:
> Of course, any setup can ultimately be understood. But the more
> complexity there is, the harder that is to do; and the more automation
> is provided by someone else, the more it encourages administration
> without understanding - in extreme cases it actively obstructs
> admini
> [...], but I DO like that it eases and therefore promotes IaC,
> programmatic configuration.
That's exactly what I don't like about it. It leads, fairly directly,
to admins who don't really understand their systems. This is fine
(well, -ish) as long as all goes well, but it falls over
catastro
Sun, Nov 22, 2020 at 09:00:30AM -0800, Hisashi T Fujinaka:
> Oh yeah, this is great. I forsee in my future:
>
> WHICH ONE OF THESE *%*( FILES IS THE ONE I NEED TO EDIT TO GET SSH
> WORKING AGAIN? ALL OF THEM? $*%)()!!!
That is matter of self-control and planning. Perhaps the more organized
perso
On Sun, 22 Nov 2020, john heasley wrote:
Sun, Nov 22, 2020 at 08:08:56AM -, Michael van Elst:
mo...@rodents-montreal.org (Mouse) writes:
https://wiki.netbsd.org/projects/project/inetd-enhancements/
When it comes to adding per-service configuration files, our current
plan is to add a ne
On Sun, 22 Nov 2020, Mouse wrote:
We are a team of senior CS students from Western Washington
University, and we are currently working a project to implement the
enhancements to inetd as described here:
https://wiki.netbsd.org/projects/project/inetd-enhancements/
When it comes to adding pe
Sun, Nov 22, 2020 at 08:08:56AM -, Michael van Elst:
> mo...@rodents-montreal.org (Mouse) writes:
>
> >> https://wiki.netbsd.org/projects/project/inetd-enhancements/
>
> >> When it comes to adding per-service configuration files, our current
> >> plan is to add a new configuration command, si
Keep in mind as you consider "changing" rather than "extending" that
there are many systems with existing files, and the NetBSD way is that
if you upgrade the system to a new version, then as little breakage as
possible should ensue. Yes, technically you should read all the release
notes, and you
On Sun, 22 Nov 2020, Mouse wrote:
I think that would be another disaster. I would look for a design that
supports the flexibility without invalidating old files and without so
much fluff, or at least without *requiring* so much fluff.
Changing the file format also concerns me. It is entire
Hello NetBSD Community,
We are a team of senior CS students from Western Washington University, and we
are currently working a project to implement the enhancements to inetd as
described here:
https://wiki.netbsd.org/projects/project/inetd-enhancements/
We are sending this email for two purpose
mo...@rodents-montreal.org (Mouse) writes:
>> https://wiki.netbsd.org/projects/project/inetd-enhancements/
>> When it comes to adding per-service configuration files, our current
>> plan is to add a new configuration command, simlar to xinetd's
>> "includedir", that allows for specification of a
13 matches
Mail list logo
