New shell server transition

Advanced feature discussion, beta programs and unsupported "Labs" features.
316 posts Page 12 of 32
by fiberadm » Tue Mar 20, 2018 7:41 pm
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 .
by tbessie » Tue Mar 20, 2018 7:48 pm
kgc wrote:
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
by scott » Wed Mar 21, 2018 5:50 pm
tbessie wrote:
kgc wrote:
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
by tbessie » Wed Mar 21, 2018 11:16 pm
scott wrote:
tbessie wrote:
kgc wrote:
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
by scott » Thu Mar 22, 2018 8:12 am
scott wrote:
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.
by scott » Thu Mar 22, 2018 8:18 am
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
by patty1 » Thu Mar 22, 2018 9:18 am
scott wrote:
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.
by scott » Tue Mar 27, 2018 2:30 pm
fiberadm wrote:
scott wrote:
[
fiberadm wrote:
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
by Guest » Fri Mar 30, 2018 12:26 am
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.
by patty1 » Fri Mar 30, 2018 9:29 am
Guest wrote:
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!
316 posts Page 12 of 32

Who is online

In total there are 9 users online :: 0 registered, 0 hidden and 9 guests (based on users active over the past 5 minutes)
Most users ever online was 487 on Tue May 05, 2020 2:07 pm

Users browsing this forum: No registered users and 9 guests