1000-1200 clients looking for work! :D

[Shuxclams]

Babbage,

The LAN Install does not have caching ability, but, I was going to add the setihide to it. I run SetiHide and SETIQ togther and am not sure what the issue is that you are describing.

PM Me and we can go over the LAN Install and how we can use setihide to use your Q over the LAN and have the service install remotely.









SHUX

 

[aberant]

hi babbage. My setihide points to Assimilator1's queue, which is done via dynamic dns. My settings are as per the image pasted and it works fine, always connecting to his queue. HTH
Settings here

 

[babbage]

Oooops

The setihide to setiqueue cache problem was a routing issue. So thats fixed

Shuxclams

Just to keep everybody upto date heres where I am at the moment

Setup one client with seti and setihide properly configured to connect to the Q

Checked that all the setihide settings were correct

Wrote a small script to copy all these files to new clients drive

using remote commander select new client, install remcmd service and run install script

Basically this copies
seti client
user_info
setihide
files FOLDER

setihide settings as follows

[SETIHIDE]
RESOURCE_NAME=local
LASTWEBSTATSID=
ASKBEFOREEXIT=1
EXIT_CLI_ON_EXIT=1
INET_BANDWIDTH_LOW=1
LOG_STARMAPS=1
USE_CPU_FLAG=0
USEALTERNATECOLORS=0
ON_WIN_STARTUP=no
START_MODE=normal
CLIENT_PRIORITY=normal
CONNECTION_MODE=online
CLIENT_TIMEOUT=120
USE_PROXY=yes
PROXY_NAME=xxx.xxx.xxx.xxx
PROXY_PORT=5517
CLIENT_EXE_NAME=c:\newinstall\seticmd.exe
CPU_COUNT=1 (default)
NETWORK_CACHE=yes
NETWORK_PATH=\\xxxxxxx\seti$
NET_RESTORE=yes
NET_USER=xxxxxxxxxxxxxx
NET_PASS=xxxxxxxxxxxxxx
USE_SOCKS=no
SOCKS_USER=xxxxxxxxxxxx
SOCKS_PASS=xxxxxxxxxxxx
SHOW_EXTENDED_CACHES_INFO=0
LOGSORTPARAMA=1
LOGSORTPARAMB=1
LOG_FILE_PATH=local
POS_LEFT=-100
POS_TOP=28
CACHE_COLUMN_WIDTH2=101

[MESSAGES]
SHOW_SettingsApplied=no

[THREADS]
C:\SETI\wu_cache_0\=-1807901
LASTID_0=-1736293
LASTID_1=-1803213
LASTID_2=-1821585
LASTID_3=-1726849
LASTID_4=-1807901
LASTID_5=3884
CPU_1=c:\newinstall\wu_cache_0\
c:\newinstall\wu_cache_0\=3884


Not sure what these threads are about???????

So remote commander copies the script to the new client, the script runs from the new client (as administrator) and copies down the relevant files. then fires up setihide hide which in turn fires up seti

Now at the moment these are not running as services or hidden, so I can see whats going on.

Next step is to use the setihide installer app as provided by Smoke, Thanks.

Basically I am nearly there

The threads part of the setihide config.ini file has me puzzled. I think I may have to delete them before running the sript as these appear to be referencing existing wu's underway.

Any major flaws in my logic here???

Regards

Babbage

PS

DPAD is going well currently at 90

OGR Havoc, sorry couldn't resist yesterday here

 

[BlackMountainCow]

DPAD is going well currently at 90

:beer::beer:

 

[Smoke]

In your SetiHide Settings, you listed the following:

USE_PROXY=yes
PROXY_NAME=xxx.xxx.xxx.xxx
PROXY_PORT=5517

I believe you said you were using your own SetiQueue to manage things internally?
Is the "PROXY_NAME=xxx.xxx.xxx.xxx" exactly what you have set or have you just used the "xxx.xxx.xxx.xxx"s to hide the actual identity from this thread?
(I think the answer to these questions are all "YES" but just want to make sure.

How many WUs do you have setup on the CACHES page?
Have you tested the "halt_if_running.txt" and verified it is shutting down what you want it too?

Since you are going to create an "image" of the SetiHide Installation Files for use system wide, you will also therein be duplicating the already downloaded WUs. This is a small issue but those duplicated WUs will not be accepted and counted toward your total processed WUs. This is a function of Seti that avoids cheating by the means of sending in the results of the same WUs over and over.

So, I would suggest you only "cache" 1 WU initially during the test period. When everything is running properly and you are ready to run the SERVICE INSTALL, you should increase the "cache to a larger number (approximately one weeks worth of WUs) and then shut down SetiHide IMMEDIATELY before it has a chance to download the WUs from your SetiQueue. That way only "1" Duplicate WU will be spread system wide and each installation will begin to fill its own "cache" with fresh, unique WUs. I hope I have not confused the situation with this "small point".

Let's make sure everything is running just the way it should before we run the Service Install. I'd let the machine that is running SetiHide finish crunching the "1"st WU and see if it transmits the results to your SetiQueue properly and is reloaded with a new WU.

We haven't discussed your SetiQueue Settings. Do you have your SetiQueue transmitting directly to Berkeley (the default)?

I thought you needed to transmit to an outside SetiQueue on Port 80 and could not go directly to Berkeley? Maybe the situation is the "default" settings on SetiQueue use Port 80 and you are good to go? Can someone chime in here and verify what Port ## the default settings on SetiQueue use to contact Berkeley?

 

[osage]

The following contains a link to a program that will install FAH on 1 to 10,000 computers at once on a network.

here.

I just came across it a few mins ago, may meet your needs. F@H could sure use the help.

 

[bgeh]

thanks osage!!!

 

[osage]

NP bgeh , anything to get a few more rigs on the TeAm.

think I'll give it a try on my little network...soon as I get done with a few of these killer 858/859 WUs

 

[Rattledagger]

Originally posted by: Smoke

So, I would suggest you only "cache" 1 WU initially during the test period. When everything is running properly and you are ready to run the SERVICE INSTALL, you should increase the "cache to a larger number (approximately one weeks worth of WUs) and then shut down SetiHide IMMEDIATELY before it has a chance to download the WUs from your SetiQueue. That way only "1" Duplicate WU will be spread system wide and each installation will begin to fill its own "cache" with fresh, unique WUs. I hope I have not confused the situation with this "small point".

I thought you needed to transmit to an outside SetiQueue on Port 80 and could not go directly to Berkeley? Maybe the situation is the "default" settings on SetiQueue use Port 80 and you are good to go? Can someone chime in here and verify what Port ## the default settings on SetiQueue use to contact Berkeley?

Have never used SetiHide, but isn't it much better to make 1 install, make sure it works, set the # to cache, and DELETE any downloaded wu before deploying to all the other machines? This way you will not get any doublets.

As for SetiQueue, already answered, but for Smoke's benefit, since Berkeley uses standard HTTP of course SetiQueue also must use port 80 to have any chance to talk with Berkeley.

 

[Smoke]

Thank you RD.

Then an outside SetiQueue or JSetiDoor will not be necessary.

If the "visible" test of SetiHide is working, I'd say it's time to try the Service Install portion of the deployment.

And of course, babage, you'll have to join the TeAm. You can do that here:

TeAm AnandTech SETI Signup Page

 

[Mucman]

Good to see some progress! Nice work you guys, and welcome to the TeAm Babbage!

 

[MDE]

Originally posted by: osage
The following contains a link to a program that will install FAH on 1 to 10,000 computers at once on a network.

here.

I just came across it a few mins ago, may meet your needs. F@H could sure use the help.

It would be huge for us, we managed to get maybe 5-8 new members from our recruiting thread in Off Topic, opposed to the huge SETI and DPAD influx.