I've now deployed the newer sc_serv build and looks like i need to do some more work on my side since the inability to write the settings to the config file is preventing the update of the running settings being correctly applied (haven't tried with the public build of sc_serv so anything is possible with that at the moment).

From what it looks like, a temporary file is used for the config file to start sc_serv which is then removed once it has loaded? If so then i can at least improve some aspects of sc_serv's handling so that my suggestion of then being able to pull from the server details i.e. admin.cgi?sid=1&mode=viewxml&page=6 would then be viable.


[edit]
ok changing the authhash works ok with the fixed sc_serv test build (silly optimisation gone wrong) though still need to improve the ui reporting when in this situation.

-daz

as an update, the new build appears to be working as expected and the sc_serv instances which were having issues in creating an authhash are now working so far including preserving of the authhash between restarts (i guess i was wrong about the temp file maybe?).

still not sure if that's just something from the test build begin used or if b29 will cope ok as well but my main focus is ensuring the test build is ok (as it appears to be) since that is almost an rc version of the next v2 release.


if there are other issues with the centrova + sc_serv v2 interactions that the dev team have question about, etc then please feel free to contact me.

-daz

Welcome, daz!

I was actually mistaken about the nature of the issue with the auth hash -- it turned out that Centova Cast was in fact simply overwriting it, plain and simple.  My apologies -- hope that didn't cause you any diagnostic aggro!

As for the permissions, I had forgotten that after I discovered that SC2 likes to write to its own configuration file (which is a bit unusual for a daemon in the UNIX world), I changed our security model to permit this.  Prior to that, for security reasons, Centova Cast ran sc_serv under a different UID than that which owned the configuration file.  That had the (intended) effect of stopping it from making modifications to files outside of its log directory.  Now it runs under the same UID so it can do whatever it likes, for better or for worse.

My YP hash problems are gone, I have a different version of sc_trans though but the process from creating the hash to editing it is seamless and error free.

it turned out that Centova Cast was in fact simply overwriting it, plain and simple.  My apologies -- hope that didn't cause you any diagnostic aggro!

no aggro at all, it helped improve the config and authhash update code so that's a good use of time.

I had forgotten that after I discovered that SC2 likes to write to its own configuration file (which is a bit unusual for a daemon in the UNIX world) ...  Now it runs under the same UID so it can do whatever it likes, for better or for worse.

yeah, i can see it being deemed as a bit strange but is the lesser of two evils as allowing the authhash management to be done in-DNAS makes things a lot easier (especially with builds without some of the issues the public build has) then having to go to shoutcast.com, registering there, creating the authhash and then adding it into the config file.

that was causing too many issues and complaints and so the in-DNAS option came about since it can be done in 3 clicks to go from and back to the server admin page if all of the details from the source are what is wanted 


well the main thing is that it seems to be working ok in combination with things which is good for all concerned.

[edit]
there we go, finally managed to post the reply. kept getting a "could not open socket" error for the last few hours trying after clicking on the post button.

-daz