[sle-beta] xinetd question

Joe Doupnik jrd at netlab1.net
Tue Nov 7 02:35:32 MST 2017


On 06/11/2017 20:23, Thorsten Kukuk wrote:
> On Mon, Nov 06, Sherry Crandall wrote:
>
>> I saw in a previous email the xinetd is no longer provided.  Our engineers have
>> used it to set up a tftp server in the past.  They are asking how to set up a
>> tfpt server without xinetd.  They thought it was a requirement.
> systemctl enable tftp.socket
>
> or
>
> systemctl enable tftp.service
>
> There is really no need anymore for xinetd.
> Between, the above is already the default for SLES12 and not new.
>
>    Thorsten.
---------
     While chasing down the details of this one may ask about how this 
works if one had to create a new service. In that chase one comes across 
a reference to man page  systemd.service(7)  which seems to be a key 
item. Alas, if one tries to read it we quickly discover the authors 
don't understand reading, only writing beyond the right margin, and we 
are left almost stranded. Try   man 7 systemd.service   to check this 
yourself. Similarly, discovering what "services" are on offer is 
carefully hidden from the view of mere mortals, so YaST is our easiest 
source of clues. Methinks we need a Siri module/oracle to ask about 
serious matters.
     We are also left wondering about the IP access controls in xinetd 
items. They appear to be omitted in the systemd jungle (meaning 
scattered widely, obscured visibility, torturous terrain). That means we 
must revert to direct control in IPtables, which we can do.
     This seems to be another instance of missing the goal of usability. 
Curiously, SUSE has done a sterling job (quality and cost) about 
usability with YaST and module installation, first rate, far beyond 
efforts by other vendors, and that counts. Yet there is a lack of 
suitable documentation to readily surmount present difficulties (see 
yesterday's "bridge over troubled waters"). I think there needs to be 
more bridge building, else we will be stranded on the far side searching 
for alternatives.
     Thanks,
     Joe D.




More information about the sle-beta mailing list