Archives

May 2001

S@H Security Update
In response to the user information files that were available for download last week, it appears that the S@H crew has now changed the user_info.sah files.� The user_info.sah files now does not include the user’s email address.� This seems to confirm the method how the information was gathered for the .zip files that were posted on the angelfire website.� This change should not affect how the client runs, BUT may affect how some of the caching programs work.� As of this moment I am not sure of any that are affected.
Don’t miss your chance, go to australian online casinos list only here good luck awaits you!

Hurry up and start winning with 25 freispiele ohne einzahlung 2020 at our casino. Limited supply!

Other add on products are a different story.� The changes in the user_info.sah file was actually discovered because of a glitch in SetiSpy.� One user noted that he could no longer update his user stats using SetiSpy.� SetiSpy used the email address included in the user_info.sah file to poll the Berkeley servers to update the stats, but since that info is no longer included, it wouldn’t work.� But Roelof, that hard working fella he is, has come through with a new version of SetiSpy and a work around for the problem.� Here is how to fix the problem (from the SetiSpy FAQ):

1. Stop your SETI Spy if it is running.
2. Download the SETI Spy 3.0.6 if you have not already done so.
3. Open the setispy.ini file in your SETI@home folder with a text editor like NotePad.
4. Add a line “BackupEmailAddr=youraddress@yourISP.com” just below the UserPercentage= line in the [Stats] section. Do not use quotes, and replace youraddress@yourISP.com with the email address you log into SETI@home with.
5. Save setispy.ini.
6. Start SETI Spy 3.0.6.

There are also some other changes with the new version of SetiSpy, check out the client history pages to see what is new. Buy best baby toothbrush. Monitor your child’s dental health.

Duplicate WUs Redux
The duplicate work unit problems people are running into seems to be due to two different things.� Many of the problems that surround the problem of work units being marked as “duplicate” usually surround database issues over at Berkeley.� I have heard that they have been working on the science database in the past couple of days so this may be one cause.

The other cause may be that the results being sent were actually duplicates.� There was some talk on alt.sci.seti about the work units that were being downloaded, and it seems that for the past several days, work units were being downloaded from the same tapes, and some people may have been downloading the same work unit more than once:

The seti data server is SUPPLYING duplicated work units!!!

Here is a batch of 200 I just downloaded.� Look how many duplicates!! (I’m using “name” from result_header.sah, shouldn’t this field be unique across all wus supplied to an individual user?)
Argh!

Shannon Hill
[snip]
name=02dc00aa.9280.10032.1022148.200 duplicate!
name=02dc00aa.9280.10032.1022148.200 duplicate!
name=02dc00aa.9280.10032.1022148.201
name=02dc00aa.9280.10032.1022148.205
name=02dc00aa.9280.10032.1022148.208
name=02dc00aa.9280.10032.1022148.21
name=02dc00aa.9280.10032.1022148.211 duplicate!
name=02dc00aa.9280.10032.1022148.211 duplicate!
name=02dc00aa.9280.10032.1022148.213
name=02dc00aa.9280.10032.1022148.223 duplicate!
name=02dc00aa.9280.10032.1022148.223 duplicate!
name=02dc00aa.9280.10032.1022148.229
name=02dc00aa.9280.10032.1022148.23� duplicate!
name=02dc00aa.9280.10032.1022148.23� duplicate!
[snip]

I checked my cache of work units from using Seti Queue, and while the vast majority of work units downloaded were from the same day (Dec 3, 2000) I did not have any duplicates….but there may be a reason why I didn’t.� Ken Reneris (author of Seti Queue) replied to the above saying:

Fyi.. version 1.6 of setiqueue will catch this as well and ignore duplicates they send that are already in your queue for the same user-id.
�- Ken

I guess the moral of the story is that WU caching can protect you on many different fronts!

Team Standings Changes
There was a notable team standings change that occurred on Tuesday that I missed.� SpeedRacer has left the Sun Microsystems team and joined up with guru on Mynoggin.� That switch knocked Sun out of the #2 team overall and moved them behind SGI Seti.� Also with the two of them joining back with Mynoggin, it vaulted them up into the #34 spot overall. There have been a couple of other notable team movement in the past week or two.� First off, SETI.Germany moved past Microsoft into the #9 spot, and is now challenging Intel.� Also, Forum Hardware.FR Team passed The Planetary Society for the #12 spot.

�

S@H Security Issues
Over the past several weeks there has been some questions about the security of the Berkeley servers and the personal information contained therein.� The first concern was noted on the news here (see May 7 under the headline “Cheating Again”).� There was one or maybe more than one person using an old hack that was thought to be closed by Eric K and crew.� I will let Eric explain:

On to the identity theft saga. A couple weeks ago I noticed the newsgroup thread from the self proclaimed cheater.� It was pretty easy to track him down and delete his account.� He was using a known cheat mechanism that I won’t bother to describe.� I also closed, (or at least thought I had closed), the loophole he was exploiting. As revenge he decided to send bogus results using the accounts of others, mostly people who decried his cheating in the newsgroup.� It turns out there was a bug in my fix and the results kept getting through.� That hole has been closed, but it will be a while before I can fix peoples’ stats. I’ve also denied access to the server to 800 or so IP addresses which the asshole and his accomplices were using.�

In a personal email from Eric, he said that the exploit resurfaced mainly because of some of the database problems that they have been experiencing, and they lost an index in the database that included the fix they had in place for this type of exploit.� There were many people who said they were affected by the episode, most of them were posters on the newsgroups.� I should know, because I was affected also.� This person(s) were able to tack on 300+ bogus credits to my account.� Apparently the “identity theft” was not theft at all.� The person just scoured the newsgroup and some sites for people commenting/reporting on the episode.� The people affected were using their posting email address (including me) for their S@H email address for their clients.� I have since then changed my S@H email address to an email account I hardly use…so that trick wouldn’t work anymore.� Also the exploit that this person(s) used did not affect the science database, so no bogus results were sent to the servers, it only affected the user stats.� Unfortunately there were many people affected, and there have been other problems with the Berkeley servers, so the people who had bogus results credited to them have not had their account totals fixed.� I’m still waiting for my totals to get corrected.

The latest “issue” surfaced a couple of days ago through email/newsgroup posts.� The post contained the following:

Dear Seti@home user.
Seti@home Webpage been exploited. We have the entire user database as well all your information.
http://www.angelfire.com/ca7/seti
SEE FOR YOURSELF.

By the time I saw this post the site had been pulled from angelfire for violating the terms of service agreement.� The site contained the “usual anti SETI propaganda” and links to to zip files with “user information”.� I had obtained a copy of *some* of the information the files contained.� It DID contain some user information, but it was information that any script kiddie with too much time on their hands can find out easily.� The information, was basically the information from the user_info.sah file that is created when running the SETI client.� That is how I believe they obtained this information.� The file started at user number 1 (David Anderson BTW) and went up.�� The script kiddies must have been able to send the Berkeley servers the user number (just start at one and go up to 3 million) and trick the server into sending them back the information for a user_info.sah file.� Contrary to what was said on the newsgroup the file DID NOT contain account passwords for the individuals in the file.� It would not surprise me at all if the person that did this was the same person that was using the exploit above.

Just a couple of days ago there was this info posted on the S@H Site which appears to be related to this latest episode:

We have received a few reports from participants who have been sent email that suggests that some SETI@home traffic has been intercepted on the Internet. We are actively looking into this and are taking it very seriously. If you have recently recieved email that begins “Dear Seti@home user.”, please forward this email to SETI@home (setiathome@setiathome.berkeley.edu).

If you have any info…send it in to them…

S@H Server Problems
Over the past couple of weeks they have also had some server problems at Berkeley.� This has caused some problems with the end user giving some “duplicate result” messages back and work unit credit lost.� This happened again today.� I am not sure what is up right now, but it does point to some more database problems.� Here is what the site had to say about the previous problems:

May 11, 2001
Last night the server started generating spurious “duplicate result” messages. The cause appears to be related to a server revision made yesterday afternoon. We’ve reverted to an earlier server version and are investigating the problem.

May 14, 2001
On Saturday, one of the RAID cards in the science database machine indicated that all of the drives attached to it had failed. Since then the server has been running as well as it can without the science database. We’re working on fixing the problem. Hopefully it won’t require a restore from backup.

May 16, 2001
After several days of attempting to fix the damage to the database, we’ve come to the conclusion that a restore is the only remaining option. We’re taking the opportunity to modify the server configuration for what we hope will be enhanced reliability. Malfunction of the RAID controllers has been the cause of most of our major outages. We’ve decided to stop using hardware RAID and move to a software RAID configuration. Software RAID will allow is to mirror and stripe across controllers, so the failure of a single controller should not shut us down or lead to an unrecoverable situation. We’re in the process of reconfiguring now. The restore should start tomorrow. There are 13 tapes that need to be restored. Last time it took about 4 hours per tape, so that’s a bit more than two days, assuming we don’t sleep.

There has also been some server downtime inbetween all of this, but there has been no word on what was up with things.

Updated SetiQ and SetiDriver
There has been some changes to two of the most popular caching clients recently.� SetiDriver is now up to version 1.6.3.3, plus there is also a beta version of SetiDriver for use with the screensaver client.� Seti Queue is now up to version 3.03.1.6.� The main improvements in SetiQ is a result of the duplicate result problem that has been happening recently.� SetiQ now handles duplicate result messages better, and sends the duplicate results into a different directory so they can be resent later when the problems have been fixed.� If you are worried about these problems, this version of SetiQ may be a good thing for you!

Now For The Good
Aside from the problems on the Berkeley front, there has been a milestone passed, and also some new features on the site.� First off, The S@H project officially reached their 2 year anniversary on the 17th of May.

Our official two-year anniversary was on May 17, 2001. Thanks to the dedication and productivity of our 3 million SETI@home users, we’ve been able to extend the depth and breadth of our project into the forseeable future. See our Project Report for updates on our status and goals.

Also there is some new features, they basically show how they are trying to analyze the data that they have gathered from the project so far.� Newsletter #7 shows how they are using “clickplots” to analyze the radio signal results they have gathered.� They give some examples of clickplots to let you mess around with them.� One thing to pay attention to in the newsletter is how they can easily spot bad results returned from clients…most likely from extremely overclocked computers.� In addition, they have added an archive some of clickplots so you can see some of the results so far.

�

Update Time
Yes it has been a while.� Sorry about that.� There should be a bunch of things to get to today, and I hope the read will be worth your time.� The first thing I want to touch on is that I am slowly in the process of moving back the stats update time each day.� Previously I have started to pull the stats at around 4:15 ET.� The download for the entire top 200 teams on a good day will take about 45 minutes, the processing of the stats would probably take another 15 min for an hour total time.� In the past couple of weeks the download times had been taking significantly longer (more abut that alittle later).� It had been taken about 1.5-2 hours to download the top 200 team data…� One reason for this is that the bandwidth hit on the S@H site is quite high in the afternoon, so I want to do the download a bit earlier to miss this rush to the S@H site.� I am going to settle in on starting the download at 12:00 pm (noon) ET….right now I am in the middle of switching the time back and the download tomorrow will be at 2:00 PM ET…and then progressing backwards an hour a day till I hit the noon download times.�� Many of you use caching programs and were uploading results slightly before the time I started the stats update.� So If you use caching, move your upload times back so they uploads are complete by 12:00 (Noon) Easter Time!

Oops….almost forgot…the weeklies are up for this past week, and also I put up the weeklies for the previous week.�� Check them out if you must!

S@H and TLC Site Down Times
In the past week or so there has been some downtime over at the S@H pages.� There was an outage on the 30th of April for quite a bit and there was an explanation on the technical news page…and here it goes:

April 30, 2001
Yesterday, the informix engine running our science database hung, apparently with a resource contention. It did so again today. We are looking into the cause. We did take advantage of the downtime to upgrade the science DB machine (one of the Sun E450’s). We added 2 more CPUs and another .5GB of real memory.

As it turns out as soon as the servers went back up after this hardware upgrade and science database fixing, the download times for the top 200 teams went back to the normal ~45 minute norm.� It seems that my downloading of the stats is a good indicator of how well their database is performing.� I am not sure exactly how the difference databases and servers are interconnected, but it seems that the performance of the database is important in their cgi scripting of their stats pages.� I am confident of this interconnection since this has happened before.� I am still going to move the stats download times back to noon though, since It will give many of you more time to browse through the stats update while many are still at work and not having to wait till they get home to take a look at them.

On Sunday, from many accounts the servers in Berkeley were down for a time also.� There is no word on the reason why for the downtime on the pages, but I am sure that It was an *unintentional* problem with the servers.� I doubt that they would be in on a weekend working on the machines/databases for regular maintenance.

The TLC pages were down a couple of times in the past week or so also for many people.� It turns out the problems were different ones, and not necessarily due to the server that the pages are hosted on.�� The first problem was apparently due to some fiber optic problems in the midwest that caused many people not to be able to view the pages.� the second problem (on Saturday) turned out to be a DNS problem in that eventually was fixed..

Last Weekend
One of the reasons for the lack of news updates in the past couple of weeks, was that I was out of town last weekend.� I had been spending time getting things ready for a trip to Boston, and time spent there.� The reason for the trip to Boston?� The Ars Technica gang was had a get together on April 28th and it was a good excuse to get away from the MidWest for a couple of days :).� For those of you who may be interested, I brought along my camera and snapped a bunch of pics of the festivities that occurred that night.� You can check them out here.� It was nice to meet Caesar, Hannibal, Ator, and Carl (of game.ars fame), and also many of the Ars readers.� A good time was had by all.

Last weekend was the first real test of my automated stats updates since there really wasn’t anyone here at home to check on the progress of the stats updates.� Things went relatively well, but there was a small problem when I got home.� The Sunday (April 29th) update was a bit slow in getting online.� This could be traced to a couple of problems, first at the time, the stats downloads from the Berkeley servers was extremely slow causing a delay, and secondly when I came home on Monday night, the stats download seemed to hang.� That appeared to be a problem with the computer here at home, and could have also been traced to problems with the Berkeley servers.� I think that the problems over there caused the stats downloads to hang.� A reboot of the machine here helped get things back on track and the stats were up not too long afterwards.

Cheating Again?
When I got home on Monday and went through the newsgroups, there were several threads which centered on a possible new occurrence of “cheating” or hacking or whatever with the S@H clients.� Alot of fur was flying on the newsgroups, but not really any confirmation of what was going on.� The furor started, I believe, from a post on the this forum.�� There was alot of accusations being thrown about, but there was no talk about just what was going on or any proof that any type of hack was being floated around or cheating that was occurring.�� Notably absent was any messages from any of the SETI Berkeley crew.� I don’t know what is up with that.

SETI Hoax
Also there was some talk or something about a possible ET signal being found and there was talk about it on the newsgroups also.� The most commonly linked page was over at the pages on a French space site.� The signal was supposedly found using the Parkes Observatory in Australia, but it all turned out to be a hoax.� This is what was posted on the Parkes Observatory page:

News Flash: 1 May 2001.
Reports have recently appeared on the internet claiming that the Parkes telescope has detected a SETI signal. (SETI is the Search for Extra Terrestrial Intelligence). These reports are totally untrue and without foundation. No such detection has been made at Parkes, and no member of the Observatory staff played any part in the circulation of this fictitious story. It appears the story originated in Geneva as part of a publicity stunt engineered by two students presenting a SETI project as part of the “Week of Science” festival.

Finally
This was passed on to my be alistar_b.� He has a page up called SETI Timer, and with this page you can insert your processor information and angle range of a work unit and it will spit out the estimated time of completion for a work unit.� It is pretty cool if you want to check out if that work unit you are running is running a bit slow or not!

�

-Front Page