On Sat, Mar 30, 2024 at 04:20:28PM +0200, cristian dragoi wrote:
>
> Should you wish to discuss this further, please feel free to contact me via
> this email address or refer to the contact information provided in my CV.
>
There was an attempt at this project a couple of years ago. There was
so
rking as a part-time
> software engineer for the past five months.
>
> I am writing to express my interest in the "Inetd Enhancements" project for
> GSOC 2024. My interest in systems engineering and a desire to broaden my
> knowledge in this area have drawn me to this proj
Thank you for your concerns,
> Wouldn't this better be a separate daemon?
I chose inetd because it is already built to spawn and monitor processes.
Creating a separate daemon would involve replicating a lot of this code into
another codebase.
Additionally, the new parameters that I am adding sh
Hi,
On Wed, May 25, 2022 at 05:25:03PM -0700, Arjun wrote:
> Hello NetBSD community,
>
> My proposal for inetd enhancements has been accepted by google’ summer
> of code. As part of the program, Brett Lymn will be my mentor. I will
> work on this project
Hello NetBSD community,
My proposal for inetd enhancements has been accepted by google’ summer
of code. As part of the program, Brett Lymn will be my mentor. I will work on
this project over the summer.
More details about the are here:
https://github.com/CCLDArjun/Google
/tech-userlevel/2022/03/15/msg013305.html)
which has some discussion of "preforking". Maybe they're working on the project,
I have no idea.
I was a student at Western Washington University and worked on the
Inetd Enhancements
project as part of a group for my senior project, until June
On Mon, Apr 05, 2021 at 10:39:52AM -0700, James Browning wrote:
> [...] our current plan is to implement it with the following syntax:
>
> !include
The reason to favor .include is that lots of other syntaxes use . for
directives, and most people's instinctive interpretation of ! (if any)
is a
>> I would argue skipping hardlinks is a [mistake]. [...]
> I meant to convey that neither hard links nor symbolic links will be
> skipped.
Ah! Then we're in furious agreement, it would appear.
>> Suggestion: provide a directive (!depthlimit?) that allows setting
>> the limit.
> This is really
On Tue, Apr 06, 2021 at 06:06:18PM -0400, Mouse wrote:
> lstat()? The rest of that sentence looks to me like a better match for
> stat() rather than lstat().
You're right, I had the behavior of lstat and stat confused.
> I would argue skipping hardlinks is a msitake. If I want to share
> config
> We plan to use standard C glob() function as well as lstat() (for
> checking for regular files), so that symbolic links will work as
> well.
lstat()? The rest of that sentence looks to me like a better match for
stat() rather than lstat().
> Any non-regular files (or non-symbolic links to regu
We are wrapping up our implementation of the new backwards compatible syntax
(thank you to Robert Elz for his helpful advice regarding the new header file
and C file). This means we are ready to begin implementing the include directive
to allow multiple files to be used for inetd’s configuration.
Date:Sun, 21 Mar 2021 19:35:54 -0700
From:James Browning
Message-ID: <20210322023554.42detea443b5dfnp@ThinkPad-T14s>
| Should we create a separate header file to move the servtab
| structure definition so we can move our new code into a separate C file,
Depends j
In implementing a key-value based syntax for inetd as progress on the inetd
Enhancements projet
(https://wiki.netbsd.org/projects/project/inetd-enhancements/), we have created
a number of new functions that rely on the servtab structure definition and some
other existing code. Should we create a
Hello tech-userlevel,
We would like to give you a small progress update, as well as inquire about
handling quotation parsing. Currently, we have implemented the framework for
the new parser, such that inetd can successfully parse a config file which
contains the old syntax and new syntax, but the
On 21-01-31 18:12, David Holland wrote:
| Alternatively you could put the glob in the include explicitly
| (that is, "include dir/*.conf"
That seems the sanest to me too; it's explicit, and it's also
following a well-established pattern used by other applications,
including: dovecot, (apache)
Date:Sun, 31 Jan 2021 18:12:21 +
From:David Holland
Message-ID:
| Basically what you want is to read only files matching some glob that
| matches the POLA reasonably well, like "*.conf".
No, what I want is for it to read the files that are there, whatever
t
> The reason to have a suffix and only read files with that suffix is
> that there are lots of ways to get extra files in the directory that
> the user didn't mean for you to read, and ~98% of the time they won't
> have the right suffix so filtering by suffix is a good way to skip
> them and avoid
On Wed, Jan 20, 2021 at 01:37:44AM +0700, Robert Elz wrote:
> Date:Mon, 18 Jan 2021 22:15:30 +
> From:David Holland
> Message-ID:
>
> | ...and also, for your own and the operator's sanity, skip anything
> | else beginning with '.',
>
> That one is pr
>>> and anything that isn't a regular file (DT_REG).
>> I don't recall whether this is relevant (it's been quite a while
>> since I did anything with d_type), but I strongly believe that
>> symlinks should be followed before any such test.
> That makes not much sense, the d_type tells you it is a s
Date:Mon, 18 Jan 2021 22:15:30 +
From:David Holland
Message-ID:
| ...and also, for your own and the operator's sanity, skip anything
| else beginning with '.',
That one is probably reasonable (and also possibly some other odd
character, to give an easy way t
> ...and also, for your own and the operator's sanity, skip anything
> else beginning with '.',
Not sure I agree with that; I'd have to think about it. I could argue
it either way. Why do you think .-prefixed entries should be skipped?
Relatedly, do you feel the same way about names beginning w
On Fri, Jan 15, 2021 at 05:43:45PM -0800, John Nemeth wrote:
> } We like the idea of being able to include files along with
> } directories. Our current plan is to implement directories first,
> } along with files if time permits us. If we don't have time to
> } implement include-a-file, then w
Date:Fri, 15 Jan 2021 17:43:45 -0800
From:John Nemeth
Message-ID: <202101160143.10g1hjbv018...@server.cornerstoneservice.ca>
| The way to implement including
| directories is to stat the item being included to see if it is a
| directory, and if it is, then branc
On Jan 14, 12:21, James Browning wrote:
}
} >I also don't like the only form of include being include-a-directory;
} >in my estimation, that wires too much policy into the mechanism. I
} >would prefer to see either two include directives, one for directories
} >and one for files, or a single dire
>> That should be true only if you specify a listening address with no
>> command. If it works that way when a command is given on the same
>> line, that's a bug that needs fixing.
> There is no bug, and it is working correctly in the way you
> described. To avoid potential misunderstandings in t
>That should be true only if you specify a listening address with no
>command. If it works that way when a command is given on the same
>line, that's a bug that needs fixing. (I feel moderately authoritative
>on this matter since I'm the person who added the code back in 1996.)
Our apologies. Th
>> inetd.conf already supports per-service overriding of the
>> listen-addr. According to cvsweb, this went in 1996-12-30 (inetd.8
>> rev 1.8, inetd.c rev 1.16).
> Itâ??s true that inetd currently supports specification of the
> listen-addr, however, the way it currently functions is that when
> [
On Thu, Jan 14, 2021 at 12:21:14PM -0800, James Browning wrote:
>
> Our reasoning behind not wanting multiple levels of includedir was to avoid
> overly complex or messy configuration systems, but we see your point. If time
> allows, then we will implement cycle detection.
>
If people want to sh
>That's not the only use for escapes. From a theoretical and aesthetic
>perspective, it would be nice to be able to get arbitrary octet
>sequences into arguments; as outlined, for example, it's not possible
>to get a newline into an argument. (Well, _almost_ arbitrary octet
>sequences. Until and
> The new syntax would look something like:
> on/off key1=value, key2=value1 value2 value3,
> key3=â??this is a valueâ??, key4=value1 value2 â??this is value3â??;
Hm. I think this is about as good a new syntax as we're likely to get.
In particular, it offers a fairly wide variety of extensibilit
thread about inetd enhancements, it was apparent a new
backwards compatible syntax for inetd.conf would be needed if we are to
implement the new features
(http://wiki.netbsd.org/projects/project/inetd-enhancements/). As suggested by
David Holland and Mouse on Nov 25, a good way for the parser to
In article ,
Greg Troxel wrote:
>-=-=-=-=-=-
>
>
>James Browning writes:
>
>> maintainers at their own discretion. Some of you brought up the concern of
>> over-automating the system at the potential risk of the configuration system
>> becoming too opaque and administrators allowing packages to
> I run servers on non-standard ports (doesn't everyone?)
No. My inetd.conf has no standard servers on non-standard ports - I
just checked my main desktop machine and my main house router. (They
have non-standard servers on non-standard ports, but that's the use
case I mentioned of wanting to ru
Date:Wed, 25 Nov 2020 03:46:43 +
From:David Holland
Message-ID: <20201125034643.ga1...@netbsd.org>
| but modulo the possibility of passing flags to
| daemons there's only one correct way to define any given inetd
| service. They are not configuration in the
James Browning writes:
> maintainers at their own discretion. Some of you brought up the concern of
> over-automating the system at the potential risk of the configuration system
> becoming too opaque and administrators allowing packages to configure inetd
> without their knowledge of what is ha
> In the case of inetd, the definition of a service is not really
> configuration.
I could quibble, but, really, this is a very important insight, which I
have seen nowhere else, leading me to think everyone else - including
me - had completely missed it. Thank you very much for pointing it
out.
On Sat, Nov 21, 2020 at 08:24:56PM -0800, James Browning wrote:
> 2. To inquire about the ideal way to implement per-service
> configuration files in inetd.
Please see the other post I just wrote, even though it's somewhat deep
in the thread. (You don't necessarily need to read the rest of that
On Sun, Nov 22, 2020 at 09:53:27PM -0500, Mouse wrote:
> Not quite. It's not about the admin having to pass a test in order to
> be one of the elite who get to use $PACKAGE. (I know that's going
> beyond what you actually wrote; it's approximately what I suspect a lot
> of people will read in
description
(http://wiki.netbsd.org/projects/project/inetd-enhancements/), users will also
need a way to specify new per-service rate-limits (with the new rate-limits
TBD). We are not set in stone about adding this new syntax, for now we just
want to spark some discussions about the pros/cons of
On Sun, Nov 22, 2020 at 02:21:24PM -0500, Mouse wrote:
> > [...], 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
>>> 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
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
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 i
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
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&qu
> 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 want to get community input, so that
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
55 matches
Mail list logo
