New shell server transition

[meyerbo2]

What machine is the web server on that is serving the files in our public_html directory? My perl scripts that make dbm calls aren't compatible. If I generate the dbm index files on the new shell server, they can't be read by the web server. Also, C programs compiled on the new shell server don't work when called as cgi programs by the web server.

I also have files on ssl.sonic.net. Is that yet on another server? How do I generate my dbm files and executables if the old shell server goes away?

Also, I have a lot of references to "http://mydomain.com/cgi/username/file.cgi" which referenced the public_cgi directory on the old shell server. These files are still being served by the web server but can't be accessed on the new server. Will this be mounted on the new server or are we supposed to be transitioning away from this usage and just put these files under public_html?

Thanks.

[scott]

What machine is the web server on that is serving the files in our public_html directory? My perl scripts that make dbm calls aren't compatible. If I generate the dbm index files on the new shell server, they can't be read by the web server. Also, C programs compiled on the new shell server don't work when called as cgi programs by the web server.

I also have files on ssl.sonic.net. Is that yet on another server? How do I generate my dbm files and executables if the old shell server goes away?

Also, I have a lot of references to "http://mydomain.com/cgi/username/file.cgi" which referenced the public_cgi directory on the old shell server. These files are still being served by the web server but can't be accessed on the new server. Will this be mounted on the new server or are we supposed to be transitioning away from this usage and just put these files under public_html?

Thanks.

Hi,
We didn't add network share mounts for cgi-bin, since we didn't think anyone would really want to use it, give we have supported cgi-bin's for years in standard web directories. However, I see you have several cgi scripts in your cgi-bin, so I'll go ahead and make this available from the new shell server.

Regarding running actual C code -- compiled on the new shell server -- on the web servers: I'll have to admit that we didn't give that much thought, thinking there really are very few people doing that anymore. But there is a good case to be made that we should still support i686 libraries for the old shell cluster, with the caveat that eventually code will have to be rebuilt for x86_64 on the new shell cluster. I'm curious how many people actually need that, though, since we have other solutions that can be used instead of loading up sh.sonic.net with i686 libraries for cross-compilation.

Finally, the matter of ssl.sonic.net: as you know, that is its own separate system -- I don't think anything we're doing with sh.sonic.net will affect that. (Please correct me if I'm wrong.

-Scott

[scott]

What machine is the web server on that is serving the files in our public_html directory? My perl scripts that make dbm calls aren't compatible. If I generate the dbm index files on the new shell server, they can't be read by the web server.

Forgot to reply about the dbm differences. If you could email me at [email protected] the path of one of your scripts, I can investigate what kind of changes will be needed to ensure it works properly. Will probably need to install a legacy dbm package on sh.sonic.net, but maybe there's something less drastic that can be done to make this work.

Thanks,

-Scott

[scott]

[
We didn't add network share mounts for cgi-bin, since we didn't think anyone would really want to use it, give we have supported cgi-bin's for years in standard web directories. However, I see you have several cgi scripts in your cgi-bin, so I'll go ahead and make this available from the new shell server.

For those who have cgi-bin directories, this is now available in /cgi-bin, with a symlink in /nfs that points to it (much like what we have now.

Note that we would rather folks use their standard web directories for cgi, if at all possible.

-Scott

[warriorz]

Hi,
Got some pointers from support about setting up mailbox specifc procmail files on the new server in my home directory and having them link them so that the mail servers can run them.

I have some questions before I do that and was hoping that someone who has done this before could help.

1) Can you tell me what to use for MAILDIR ?
2) Where are log files stored, under the main account ?
3) If the answer to (2) is yes, what permissions are necessary on the log file
4) It sounds as though procmail will not be writing to spool folders directly but piping to imap ? If so what is the file path for specifying an imap folder eg "test folder" in a recipie ?
5) I presume there is no need for a .forward

[scott]

Been wrestling with at(1) execution, looks like there are weird side effects from selinux and chroots.

How many folks are actually using at(1)? It might not be worth supporting, especially considering that crontabs work fine...

-Scott

[scott]

Hi,
Got some pointers from support about setting up mailbox specifc procmail files on the new server in my home directory and having them link them so that the mail servers can run them.

I have some questions before I do that and was hoping that someone who has done this before could help.

1) Can you tell me what to use for MAILDIR ?
2) Where are log files stored, under the main account ?
3) If the answer to (2) is yes, what permissions are necessary on the log file
4) It sounds as though procmail will not be writing to spool folders directly but piping to imap ? If so what is the file path for specifying an imap folder eg "test folder" in a recipie ?
5) I presume there is no need for a .forward

Hello,

procmail runs on the mail delivery systems, not the shell server. It has access to your mail spools (and indeed, needs them to deliver your mail).

If you want to, use procmail to deliver to a MAILDIR path under your home directory (such as /home/w/warriorz/Mail -- don't forget to create the directory first!) You can also set DEFAULT to point to a file (or directory) under your home directory, if all you will be using is the shell to read your mail.

MAILDIR defaults to your home directory, if not set.

Log files are written with your own permissions, so no worries about making sure (say) "daemon" can write to them. There's no logfile by default, but you can set one at the top of your .procmailrc like this:

LOGFILE=/home/s/scott/procmailrc.logfile

No need for a .forward file, just a .procmailrc.

Hope that covers everything -- let us know if any further questions.

-Scott

[warriorz]

Thanks Scott,

One last clarification. I want to forward mail to the IMAP folders. What path do they appear under ?

[joemuller]

Thanks, mediaeng, for the log information.

Any ideas about the cgi directory?

Your CGI-bin is symlinked as public-cgi in your home directory. Alternatively it should be directly reachable on shell.sonic.net at /cgi-bin/chongo/.

-- Joe

[slapout]

How do I run the ancient calendar program, "pal"?
a dozen years ago I learned some unix for the purpose off running pal twice a day in cron, with two sets of parameters.
In oldshell I traced it to

slapout~: whereis pal
pal: /usr/bin/pal /etc/pal.conf /usr/share/pal /usr/share/man/man1/pal.1.gz

It still executes in oldshell. How do I get it to execute in sh? (sh.sonic.net)