1. Do not do any of the "chmod 0777" or "chmod 0666" commands that they tell you to. These are only needed if gallery will be run as the web user.
2. After you have untarred the gallery package, cd into the gallery directory and run the command "find ./ -name \*.php -exec chmod a+x {} \;" to make all the .php files exectuable by the web server.
3. Follow their instructions to execute a "touch config.php .htaccess", but do not execute the associated chmod commands.
4. Go to http://url/gallery/setup/index.php
5. Make sure there are no extra warnings other than "Apache is not obeying the 'php_value' lines in your .htaccess file." (If you are running PHP in CGI mode, this message is unavoidable)
6. In the setup wizard's Location and URL page set the Temporary Directory to /tmp

After completing these steps gallery should be ready to go! If you have problems, please let us know so we can update the instructions.

SuEXEC for CGIs and PHP scripts

Since one of the most common uses for PHP scripts on Radix is personal web galleries that people have set up, and due to the general inconvenience of running all PHP and CGI scripts as a single "www" user, we're going to configure Apache's SuEXEC module so that any CGIs and PHP scripts run from your home or web directories will be executed under your user id. This means that you will no longer need us to chown album directories to the web server and that you will be able to directly manage the files under your gallery directories.

Changes to make: We will be configuring the web server to automatically run PHP scripts in CGI-mode. This means that existing scripts that are interpreted directly by the web server will need to be made executable so they are runnable as a CGI. We've configured the OS to automatically recognize .php files and run them with the proper interpreter, all you need to do is chmod them so the Apache server can execute them. This can be done for all .php files under your web directory by running the following command from your public_html directory:

find ./ -name \*.php -exec chmod a+x {} \;

Making .php files executable is safe to do even on library files.

Changes to make: Since PHP and CGIs will be running as specific users, old installations of Gallery or other tools that write to the local filesystem will now be running as your UID. This means that the old album/ directories will be owned by the wrong user. We're *not* planning on doing a mass chown of files in web directories back to the original owners simply because we're not sure what people have changed and what they haven't. This will fall in to the "you'll need to look at your system and test it to make sure its working" category. Expect further recommendations on setting up Gallery itself.

Implementing VirtualDocumentRoot

To remove the need for multiple special-case configurations in Apache's httpd.conf we're going to standardize on one configuration that applies to all domains Radix hosts. This means essentially that a request for http://domain.tld/ will automatically look in /www/domain.tld/doc for HTML files and /www/domain.tld/cgi-bin for scripts to run (more on CGIs below). This is an incredibly simple way to set up the system, but it doesn't automatically handle server aliases like http://www.domain.tld/ (which some people use and some don't).

Changes to make: If your domain is regularly accessed using something other than the standard http://domain.tld/ configuration you will need to let us know what ServerAliases you want to configure to support. Please only consider doing this if you have www.domain.tld published far and wide, as its simpler for everyone (us, you, Google, statistics generators, etc) to standardize on one domain.

.htaccess AllowOverrides

To get rid of special-case cgi-bin and directory access configurations in the global httpd.conf, we're going to open up the use of .htaccess files for pretty much everything you can configure, from authentication to CGI control to error pages. This means that essentially every configuration option you might want to tweak for your site will be available to you by modifying these files in your web directories. An excellent overview of what kind of flexibility you will have can be found here:

http://httpd.apache.org/docs/howto/htaccess.html

When you read this page you'll notice that Apache actually recommends against people using .htaccess files for a couple of reasons, one of which follows:

The second consideration is one of security. You are permitting users to modify server configuration, which may result in changes over hich you have no control. Carefully consider whether you want to give your users this privilege.

We're doing this to make everyone's life easier, so we're again reminding people to follow our general terms of service: "Don't be a hozer, ehh."

If you're curious as to what specific changes we made to the configuration file, they are documented here.

You can use the "quota" command from a shell prompt to easily see how much disk space you are currently using.

But the news keeps getting better. The full image snapshot has been corrupted. Right now I've only been able to pull about 5 home directories off. I don't know if we'll get any more unless we can find a TAR recovery tool. The best bets to look for recovered data are in:

/srv/RECOVERED/public/old-backups/partial-full-2004-04-26/home
/srv/RECOVERED/public/old-backups/incr-2004-05-22/home

We'll let you know if we pull anything else useful out of here.

We are moving to a monolithic /home disk for all user data. This means that what you used to put in /crypt/users, you should now put in your home directory. We are keeping local snapshots of the home directories, but there's too much data in there to perform off-site backups. We have currently deployed a 2 Gigabyte quota on /home for all users, and a shared 10 Gigabyte quota for anything owned by the Apache user (this means all "gallery" installations will be subject to a shared 10 Gigabyte quota). More news to follow.

So to sum up:

• Copy data from /src/RECOVERED/public/crypt-users to your home directory (this directory will eventually go away)
• There is a 2 Gigabyte quota for all users on /home now

Thunderbird

Go to Tools :: Account Settings, then select "Outgoing Server (SMTP)" on the left-hand side. Set the following:

• Server Name: radix.cryptio.net
• Port: 587
• Check the box next to Use name and password
• User Name: (Enter your regular user name here)
• Use secure connection: Select TLS

Now you should be able to send mail through Radix. When you first try to do so it will ask you to accept the TLS certificate presented (we'll have something to quiet that down later), and then ask for your password. This is the same as your usual Radix password. You should be all set!

Also, WRT to data recovery, we've copied back all the home directories we were able to recover. If your data isn't there, we couldn't recover it. We have the disk though and may consider hiring a professional data recovery service if there are enough people who want to chip in for it (our only hesitation is that these folks are usually very expensive for only a marginal rate of success).

/crypt/users was unaffected and is currently copying over to the new box at a very slow pace. I wouldn't expect all data to make it over for the next week or so (we're talking nearly 100 Gigs of photos and what not).

The old backups are also copying over, and should come online sometime after this weekend. We'll note when they are available.

Everything that we've been able to recover and that is safe for public consumption is availabe in /srv/RECOVERED/public/. We've already copied over everything that has completed a copy, so the only reason to look here is to see if maybe your /crypt/users directory got copied over earlier. DO NOT COPY THIS DATA TO YOUR HOME DIRECTORY YET.

Note that we are currently running without a net, there are no backups being performed and there is no disk space management happening on /var (where /home is currently located). If any single user fills up the disk it will stop machine operations for all other users.

https://radix.cryptio.net/squirrelmail/

If you have trouble logging in, please email root@radix.cryptio.net from a separate account. If you have no other access to email please contact your friendly admin directly between the hours of 9am and 9pm Pacific time.

At this point the most essential services are up and running, so we are going to try and get some sleep. Some things will come back up over the weekend, and we continue to transfer data from the old disks to the new ones, which should complete some time next week (there is a lot of data).

As of Wednesday morning, recovered data is being fed on to the new hard drives and we are working to restore basic services such as shell access, mail processing, and web mail access. We hope to have the system stabilized for public access sometime on Thursday, March 17.

DNS requests for domains hosted on radix are distributed over a network of machines unaffected by this issue, and email bound for various domains is being queued at various locations for delivery when the system comes back up.

Please continue to visit this web page for further information.

https://radix.cryptio.net/squirrelmail-1.4.4/

Same deal as before... Please test it out and let rootclub@cryptio.net know if you have any problems with it. This new version fixes the bugs that I've been told about as of now.

Thanks for your feedback!

In order to make this happen though, some old behaviors have to change. In particular, we need to make sure that all mail that is legitimately sent from a domain routes through the specified mail servers for that domain. This means that users who are sending messages through their ISPs mail systems or their work mail systems, but using your personal address @cryptio.net (or others) will need to change to delivering mail through Radix itself.

If you only ever use SquirrelMail (web mail) or log directly in to Radix to email through Pine or Mutt, you have nothing to worry about. If you use a desktop email client such as Outlook, Netscape/Mozilla/Thunderbird, Eudora, or Mac mail, even if you do so only occasionally, then you're going to need to take steps to make sure that your mail is properly routing through Radix. The easiest way to do this is to look in your mail server settings and see that your "Outbound Mail Server (SMTP)" is set to "radix.cryptio.net". If its not currently THEN DON'T CHANGE IT, but instead email us so we can have some idea of how many people we're going to need to set this up for.

The risk of sending your mail through a non-authenticated server is that as receivers start to check messages for this kind of information, they may consider your spoofed but otherwise legitimate messages to be unacceptable and they may start to reject or discard them.

Please let us know if you have any questions about these topics and we'll keep you updated on our progress.

Rather than risk power spikes, I'm going to shut radix down before I leave for work, and will restart it as soon as I get back.

Sorry for the short notice; I just found out myself this morning.

Any questions or concerns to rootclub@cryptio.net.

-Mark

To get started, you can jump right in to Radix's MT-Blacklist Configuration Page, and you might even want to read the MT-Blacklist manual.

With this new tool in place, I've gone ahead and re-enabled the commenting functionality for the rootblog.