Description of Problem:
linuxconf web interface does not work
Steps to Reproduce:
1. ntsysv , activate linuxconf
2. linuxconf, activate web access
endless select, accept loop
linuxconf web gui
Same thing happens for me. If I telnet in to localhost port 98 xinetd opens the
connection, but offering the HTTP command "GET / HTTP/1.0" doesn't do anything
(same happens with Netscape and Lynx). Further, when I kill the telnet session
with ^], linuxconf still runs in the background, and according to top, uses all
the cpu (98%).
BTW, start linuxconf with
$ linuxconf --http
then it will listen to port 3000, http://localhost:3000
Ok, that doesn't even come close to working. linuxconf --http does not listen on
any port. Running "netstat -l --numeric-ports" even shows that nothing is
listening on port 3000. Of course, you can't telnet or point a browser to it
either. From my experience with xinetd services (some could be different), they
operate on stdin and stdout. Running "linuxconf --http" (which, by the way is
what xinetd runs. see /etc/xinetd.d/linuxconf-web) sets it up to receive http
commands (thru stdin) and send back html (thru stdout). Neither of these involve
listening on any port.
You have to enable the http mode in the linuxconf GUI first!
I am seeing the same looping behavior on RHL 7.1, too. Bugzilla issue #40303
seems relevant, and was helpful to getting the proper configuration established
and port assignment done. However, it still doesn't solve the looping problem
on my system, although the submitter indicates it did the trick on getting a
usable linuxconf working on his setup.
recently posted on red hat updates ftp site
xinetd v. 2.3.0 solves the problem of initial
browser connection, but when it comes to the Accept change,
the browser indicates broken connection (lynx message:
"Unexpected network error; connection aborted").
At the same time, xinitd syslog entry pops the message:
"warning: can't get client address: Transport endpoint is not
Closing because we don't ship linuxconf anymore
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.