This is a full RH7.1beta1 install. No tweaks. I fired up the KDE2 desktop. Unfortunately, using "netstat -ao", this exposed a KDE2 listening socket in the default config!! The guilty process was "kdeinit". If possible this listening socket should be slayed mercilessly. We've only just managed to get GNOME tcp-socket free by default, it would be nice to keep KDE in this state too. Note that this is a regression from RH7.0, which used KDE1.1, which did not have this problem.
Where exactly are you seeing this? I can see kdeinit listening on a unix socket only (in the current version, meaning 2.0.20010102).
Can't see it here as well (palin beta1 install).
Assuming it's misread netstat output, closing
No its definitely there for me Full install of everything, BETA1 Logged in via gdm, selecting "KDE" session "netstat -ao" shows tcp port 1025 listening (1024 taken by rpc.statd) lsof -i tcp:1025 shows the guilty party as "kdeinit: kxmlrpcd" If you still don't see it, perhaps we can leave the bug open and I'll check beta2 when it arrives soon.
Definitely not happening here; can't telnet to port 1025 either (just in case my netstat is buggy ;) ).
kxmlrpcd listens on a tcp socket and is intended to do so. It's most definitely not started by default though, both by checking and proofreading the code.
Thanks for info - will check with BETA2 or BETA3. Any idea what I may have done to get "xmlrpcd" to launch when I log in? Does running up a certain application activate "xmlrpcd"?
Re-opening after playing with BETA-3. My desktop is in a state where kxmlrpcd starts by default. I run up konqueror, did some web browsing, and looked at my home dir too. I also had some KDE terminals running. Now the desktop starts xmlrpcd by default and listens on a TCP socket. This is dangerous because - The medium security firewall won't block it, since it's a high port. A _lot_ of desktop users will only have the medium firewall due to IRC, ICQ, etc.
[2.1-5] Ok, I've made kxmlrpcd listen on a UNIX socket instead. This totally breaks its functionality though, but there's nothing that can be done about it. You can't do remote scripting without listening on a tcp socket... To re-enable the functionality, add [KDE] RemoteScripting=true to kdeglobals.