Last night, due to the high traffic I was grousing about yesterday, the workunit storage filled and therefore no new work could be generated, so we ran out of stuff to send to clients. This cleared up on its own this morning, but then we started the regular weekly database maintenance outage, so we'll be in a bit of connectivity pain for a while.

During the outage I tested the stability of our secondary science database server (bambi). In other words: will it survive reboot without missing drives? It did. So that project is more or less done, and we'll start focusing on the primary science database server (thumper) next.

Even more exciting is that Jeff and I added a couple more servers to the closet today: sidious and casper. The latter is a multi-purpose machine used by the tangentially related CASPER project. The former is the replica mysql database. We were happy to finally get it out of our "test lab" and into the closet because it's big, noisy, and there's a chance its particular network hangups will be solved by moving it physically closer to its friends (all talking over one switch, as opposed to traversing at least three). We have only one major server left to move into the closet: vader. This is all good news but we're kind of maxed out on power usage in the closet, and need to do some breaker tests before adding anything else.

- Matt

---

-- BOINC/SETI@home network/web/science/development person
-- "Any idiot can have a good idea. What is hard is to do it." - Jeanne-Claude

Seems like you had quite a busy day. Hope things all work and moving the servers prove to be the right course of action.

Thank you as always for your updates and lets all be patient people. No complaining of no work until things all settle down.

Do they still charge people to go into Wire pass narrows?
Amazing scenery in Utah and surrounding area. Would love to go back there someday.

---

Nice work Matt & All!
Did Outage began slightly earlier today? I woke up this morning to find you were already working on maintainance... Or did I just wake up late?

- Luke.

---

- Luke.

https://setisvn.ssl.berkeley.edu/svn

Does the web interface or the SVN link require special permissions now?

https://setisvn.ssl.berkeley.edu/svn

Does the web interface or the SVN link require special permissions now?

Yes at that level, but these work:

https://setisvn.ssl.berkeley.edu/svn/astropulse/
https://setisvn.ssl.berkeley.edu/svn/branches/
https://setisvn.ssl.berkeley.edu/svn/datarecorder2/
https://setisvn.ssl.berkeley.edu/svn/seti_boinc/
https://setisvn.ssl.berkeley.edu/svn/seti_science/
https://setisvn.ssl.berkeley.edu/svn/setilib/

Eric noted someplace awhile ago that Matt has added something to the repository which needs to be protected. That suggests it should be Matt who updates the broken "Web interface" link on Porting and optimizing SETI@home with a list of the parts of the repository which are still publicly available. The CUDA parts are in .../branches/seti_cuda/ by the way.

                                                                  Joe

Glad everything is working again, great job guy's.
Hi, this what I get, trying to access the above adress:
setisvn.ssl.berkeley.edu:443 gebruikt een ongeldig beveiligingscertificaat.
Safety certificate is not valid
Het certificaat wordt niet vertrouwd omdat het zelfondertekend is.
Het certificaat is alleen geldig voor <a id="cert_domain_link" title="setibase.ssl.berkeley.edu">setibase.ssl.berkeley.edu</a>.

The certificate isn't trusted, because it is selfsigned and only valid for
<a id="cert_domain_link"
(Foutcode: sec_error_untrusted_issuer)
Strange, it is just a (safe,) secure adress (HTTPS), isn't it?
{ADDED}Missed your answer, Joe, good evening, by the way, you were faster ;)
Thanks anyway!

---

I got that as well, I just added an exception and went right in.

---

Hi Arkayn, ofcoarse, but I had never seen this type of error, accessing a https page.
And instead of port 80, port 443 is used for this.

---

I have seen it on several servers, so know how to fix it. On secure servers as well.

---

Thank you Matt for your great updates.

---

https://setisvn.ssl.berkeley.edu/svn

Does the web interface or the SVN link require special permissions now?

Yes at that level, but these work:

https://setisvn.ssl.berkeley.edu/svn/astropulse/
https://setisvn.ssl.berkeley.edu/svn/branches/
https://setisvn.ssl.berkeley.edu/svn/datarecorder2/
https://setisvn.ssl.berkeley.edu/svn/seti_boinc/
https://setisvn.ssl.berkeley.edu/svn/seti_science/
https://setisvn.ssl.berkeley.edu/svn/setilib/

Eric noted someplace awhile ago that Matt has added something to the repository which needs to be protected. That suggests it should be Matt who updates the broken "Web interface" link on Porting and optimizing SETI@home with a list of the parts of the repository which are still publicly available. The CUDA parts are in .../branches/seti_cuda/ by the way.

                                                                  Joe

I just tried to access the seti_boinc url via TortoiseSVN and was blocked for authentication. In fact if I use http://... then SVN tells me that the repository has been moved to https://... . Then I get the authentication request and am blocked access.

Sometimes sysadmins forget about power consumption and can easily overload a rack. Obviously, you know this! I hope you can find a happy home for vader somewhere in the closet.

Sometimes sysadmins forget about power consumption and can easily overload a rack. Obviously, you know this! I hope you can find a happy home for vader somewhere in the closet.

They have been reminded a couple of times by blown fuses that this is a problem...

---

BOINC WIKI