New shell server transition

[fiberadm]

BUT - I just noticed the section on "Custom php.ini file"
in https://wiki.sonic.net/wiki/Php5
I don't need this myself, but you might see if this still makes sense,
without access to ~/public_cgi .

[tbessie]

Procmail will continue to work as expected and I'd go ahead a migrate your cron jobs over to the new server now.

I'm a little confused. The Shell Access Transition page:

https://wiki.sonic.net/wiki/Shell_Acces ... Transition

... says "There is no longer direct access to email spool directories -- please use IMAP."

I'm currently using procmail to filter into separate IMAP-accessible folders. However, when I asked about this elsewhere (here or with a support person, I can't recall), I was told that procmail accesses the mail spool locally on the shell server (/var/spool/mail). But if the shell server can't access them, how will procmail continue to work?

- Tim

[scott]

Procmail will continue to work as expected and I'd go ahead a migrate your cron jobs over to the new server now.

I'm a little confused. The Shell Access Transition page:

https://wiki.sonic.net/wiki/Shell_Acces ... Transition

... says "There is no longer direct access to email spool directories -- please use IMAP."

I'm currently using procmail to filter into separate IMAP-accessible folders. However, when I asked about this elsewhere (here or with a support person, I can't recall), I was told that procmail accesses the mail spool locally on the shell server (/var/spool/mail). But if the shell server can't access them, how will procmail continue to work?

- Tim

Hi Tim,

procmail actually runs on servers in a dedicated mail delivery cluster. It should continue to run and file your mail.

-Scott

[tbessie]

Hi Tim,

procmail actually runs on servers in a dedicated mail delivery cluster. It should continue to run and file your mail.

-Scott

Ah, good to know! I thought that procmail actually ran on the shell server and mounted filesystem combination that I use (the shell server itself).

- Tim

[scott]

So we've been ironing out the bugs on the new shell server for a few weeks -- and while there are still a few things to work on, there doesn't seem to be any reason why folks can't switch to using the new server.

The Shell Access wiki page started to get a bit unwieldy, and it contained extra information that would be going away after the transition. So, I've created a Shell Access 2018 Transition page to house information specific to the transition.

Again, please post here any public feedback or queries, so that other readers can gain the benefit of the answers. For private items, such as those pertaining to security, please email shellmaster@sonic.net .

We're thinking of trying for March 15th as a time to start restricting access to the old shell server. However, that is somewhat flexible, as we don't want to leave anyone behind.

-Scott

Obviously this didn't happen on March 15th. Given the issues we are still facing, somewhere around April 5th seems like a more likely date, perhaps even as far as April 12th.

[scott]

Saw a few segfaults from folks trying to run a tinyfugue binary from Bolt (I'd imagine). Binaries from Bolt may or may not work, depending on how long ago they were linked.

In any event, I just installed tinyfugue from the CentOS repositories. Let me know how it works.

-Scott

[patty1]

Obviously this didn't happen on March 15th. Given the issues we are still facing, somewhere around April 5th seems like a more likely date, perhaps even as far as April 12th.

Thank you for being flexible about this, Scott. I run only a few shell processes and everything seems to be going well on both machines for me, but I appreciate that you're working with other users to make sure that all of their tasks run okay on sh.sonic.net.

[scott]

[

ALSO: where is my cgi-bin ? (was at /usr/local/lib/httpd/cgi-bin/$USER )

I didn't mount that hierarchy because I didn't think anyone still used separate cgi-bin directories. (You get the same effect in your web directory nowadays, given the proper filename suffix.)

Do you need an explicit cgi-bin directory?

-Scott

OK, I don't need ./cgi-bin/ anymore, and have emptied it out.
(BTW, I used the web error log, while figuring out some things about this.)

So, I presume that *.cgi and *.php are treated like cgi-bin.
Any others suffixes do the job?
(Could you perhaps list here the relevant section of the Apache config?)

Thanks, -LenW

Sorry, missed your question here!

Configuration is very basic:

Code: Select all

    AddHandler application/x-httpd-php            php3 php4 php
    AddHandler cgi-script .cgi
    AddHandler server-parsed .shtml

You can change this behavior with .htpasswd.

-Scott

[Guest]

Scott, thank you for adding that Mac to the list. Between the Mac addition and changing the SSH2 authentication type from "Password" (used on Bolt) to "Keyboard Interactive" (used on SH), the client now automatically connects without delay. I have run into some issues on SH, such as the new UPTIME and WHO commands, which do not fully work or at all (respectively). The RAR command is still missing. I'm still not entirely sure what to do with the "public_media" link, it doesn't work on Bolt or SH, and I don't know if the target is meant to be permanently gone. The new PS command works differently and that's causing a minor display issue. Can the PAR2 package get installed? The SH auto-logout isn't graceful. There could be other issues, but I haven't had the time to investigate further.

BTW, when the dust settles you guys should come up with a snazzy name for the new shell machine. "Bolt" has character, "SH" sounds like a disproving wind instrument assigned to a library. ;)

Vic, do you know what the status of FRM is and will FRM be updated to fully work on SH?

Casner, because to upgrade the client would cost $100 and that only buys one year. I accept donations. :) Yes, I know PuTTY is free, but to be completely honest, PuTTY sucks dead bunnies through a straw. From what I understand, KiTTY, based on an older version of PuTTY, is suppose to fix some PuTTY issues, such as the password, but I'm not convinced it's trustworthy.

[patty1]

BTW, when the dust settles you guys should come up with a snazzy name for the new shell machine. "Bolt" has character, "SH" sounds like a disproving wind instrument assigned to a library.

Vic suggested in the Disk Quota thread that the new one be called "nut". Personally, I always thought that bolt referred to a bolt of lightning, not a piece of hardware; perhaps one of the Sonic oldtimers can clarify its origin for us. But "nut" would result in nut.shell.sonic, which is kind of cute.

I agree that "sh" is awkward. I find myself referring to bolt as just that, but sh looks like a UNIX command, so I have to type its full name of sh.sonic.net. A clear single name would be preferable.

There have been some delightful node name themes in networks I've run across over the years, such as the Bambi-themed ones at Bellcore (bambi, thumper, flower, etc.). Sonic folks, here's your big chance to come up with a memorable name for the new shell machine!