What if I do NOT want to be in YP???
 

OK, I do have another post requesting more detailed info, but heres the simple question: What do I do on a linux system if I do NOT, repeat, NOT want to be seen on yp, don't want to attempt to contact yp, and never wanna see the [yp_add] sections in my logs? The server running this is heavily firewalled, and will never be allowed to communicate ******d on ports 80 or 666. Also I have an issue occuring with the attempt to contact yp and connectivity (see other thread).

My settings of importance are:

Yport=666 (Can I just comment out that whole setting?)

PublicServer=never
AllowRelay=No
AllowPublicRelay=No

BUt yet the logs continuously show attempts to connect to yp.shoutcast.com!

Drom

(Edit) Huh??? The above censored word is "o u t w a r d".. Why is *that* being blanked out???

In your Shoutcast DSP under Output>>Yellowpages un-check "Make this server public".

Thanks John. This is not a gui system though (linux based).

All settings are set to no.

At this time I have commented out the YPort line. It appears to have made the system much more stable but the logs still show the yp_add error.

Still dazed and confused!

Drom

My bad. I'm sure Fester can give it a look though :igor:.

Still dropped connections even after the commenting out of the YPort line.. Back to the drawing board I guess...

D

OK, what I've done for the time being is put 127.0.0.1 yp.shoutcast.com in the /etc/hosts file, then put the file addsrv just off the internal webserver homepage, containing :
icy-response: nak
icy-error: upgrade to shoutcast 1.8 or newer

Now the errors seem to be simply that error message... Sorry, but this seems like a definate glitch or future feature and not something that should be happening.....

Drom

Check out the DNASs sc_serv.ini/conf configuration file for the section (default shown below):

code:
; PublicServer can be always, never, or default (the default, heh)

; Any setting other than default will override the public status

; of the source plug-in or of a SHOUTcast server that is being relayed.

PublicServer=default

Change PublicServer to "never" (sans quotes) and restart the DNAS.

One of the first things I did, unfortunately. It didn't stop the attempts to connect. Almost as if in the linux version that field is being ignored...

So far I've been up a worlds record of 85 minutes without a drop! Also all my testers have noted no drops either. All I did was the above solution. Now the logs show the error message in the file but thats it.

The problem is very easily reproducible. Just put the broadcaster station (sc_serv) *behind* a firewall and prevent ANY outbound traffic besides the necessary stream port. The error will begin in the logs no matter what the setting is. Interestingly you would have to get a response from the yp server to get the more familiar NAT warning... In this case though you can never get to the yp server initially.

Uhh, maybe I missed something though. Will a kill -HUP reload the config file? I've been doing that rather than a full stop and start.

Drom

(Time to do a grep on the setting PublicServer in the binary...)

kill -HUP closes and reopens log files. kill -WINCH will reload some settings from the config file, but not all. The PublicServer value is reloaded in that case. Check out the included Readme file for the full list.

it sounds like the server is not loading the configuration file you think it is, be sure that your server is loading this file it will honor the PublicServer setting. Also any source application can stop the server from being listed by passing it a 'icy-pub: 0' how to configure such applications to do this is dependent on how you source the server. The method provided for the DSP plugin has already been mentioned.

sc_trans_linux is loaded on the cap system and icy-pub *IS* set to 0 on that one. That was what I first tried; then I set sc_serv to be PublicServer=never and still get the log errors.

<time passes>

OK, just did a full kill and restart. At this point it looks like its behaving properly! I'll be dipped... I guess I am so used to a -HUP reloading config files I didn't even think of a full kill...

You guys are the best!

Drom