Bug 34817
| Summary: | !! xinetd starts ftpd when man page says it WON'T !! | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Need Real Name <jdh> |
| Component: | xinetd | Assignee: | Trond Eivind Glomsrxd <teg> |
| Status: | CLOSED NOTABUG | QA Contact: | David Lawrence <dkl> |
| Severity: | medium | Docs Contact: | |
| Priority: | high | ||
| Version: | 7.0 | Keywords: | Security |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2001-04-05 18:43:59 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
ftpd doesn't listen on port 23. Are you sure that's what you're seeing? Actually, I'm sure he didn't. Also, he claims to have installed RHL 7.1 from isos - and I now that disable works. This is a bogus report. |
Hi, I have just freshly installed redhat 7.1 re i386 iso I've used linux on and off since 91 or 92. xinetd has a naughty ftpd problem which [is not] yet in any problem report. xinetd's man page states, for "/etc/xinetd.d/*", if disable == yes for a service that xinetd, when a request for that service on the port arrives, WILL REFUSE the connection. -------------------------------- HOWEVER - xinetd DOES START ftpd on port 23 despite its flatulent claim! (no, no ftpd daemon is or was loaded) -------------------------------- I have read the man page. It is wrong: that is an error that needs attention. xinetd shouldn't launch services on ports it has "no configured knowledge of"; as per manpage exposition. Infact - inetd (Linux NetKit 0.17) has been tried and tested. However: xinetd has had at least 5 fixes already. xinetd wasn't initially linuxconf ready (and so valuable linuxconf contributor time was spent 'fixing it): I'm wondering just how xinetd got chosen as a viable unix base system solution. It just isn't all that: the author didn't even claim it to be. Why the name change that breaks scripts (that steer inetd)? Why change the well known super-server fields in the config file - which up until now have been similar across platforms? Will the linuxconf "fix" that made \[Xi]netd actually work keep me from using the inetd from: "Linux NetKit 0.17" with redhat? If it does - I'm telling! (Or, I'll just not be as happy as I would normally be.) Thanks, hope that helps, John D. Hendrickson jdh johndhendrickson22124 P.S This is like strike six for xinetd, right? How many strikes does it get anyway? Is an imperfect kerberos implementation really important? Kerberos doesn't have three heads -- it has 100 configuration sides. I mean, an NIS+ configured subnet with stunnel-only connects is good too -- and offers the same opertunity for password upgrade binges, host-host tunneling, secure administration, etc... And anyway? If kerberos is so great, how come they're "begging" it be exported? Ok - maybe I'm out of my realm on the encrypted configurable network point. Still - stunnel is easier and doesn't require application re-writes for transport independant (unix) apps, and Kerberos does (kerberiz#q*^&) Right? Anyway, Have a good one.. jdh