Page 32 of 32

Re: New shell server transition

Posted: Wed Dec 05, 2018 1:04 pm
by casner
joemuller wrote:
I've double-checked our logs, and indeed - your site didn't receive any hits on December 3rd. Still strange that *no* file was written - even an empty one.

Thanks for checking.

Re: New shell server transition

Posted: Mon May 27, 2019 11:42 am
by etnahouse
scott wrote:
scott wrote:
sls123 wrote:
I am unable to figure out how to get gpg version 2 to work. I've tried all the hints from the internet but still unable to create a socket. The '--no-use-agent' is obsolete. bolt has gpg v1 installed. I would appreciate a v1 gpg on the new shell server or some black magic to make gpg 2 work.

Thanks!


I get "Operation not permitted" no matter where I attempt to create the socket:

% gpg-agent -v --daemon
gpg-agent[19014]: error binding socket to `/home/s/sls123/.gnupg/S.gpg-agent': Operation not permitted
%


% gpg -d <redacted>

You need a passphrase to unlock the secret key for
user: <redacted>
2048-bit ELG key, ID D2BE73CD, created 2014-01-01 (main key ID E0789D87)

gpg: can't connect to the agent: IPC connect call failed
gpg: problem with the agent: No agent running
gpg: encrypted with 2048-bit ELG key, ID D2BE73CD, created 2014-01-01
<redacted>
gpg: public key decryption failed: Operation cancelled
gpg: decryption failed: No secret key
%


Ah, that is due to home directories being mounted with sshfs, which doesn't support Unix sockets. I will take a look at this, have some ideas how to fix it.

-Scott


Try it now, should be fixed.

I had to build gnupg without the option that puts the agent socket in the home directory -- it lives in /tmp. (Since each login has their own /tmp in their own chroot environments, that won't be a problem.)

-Scott


gnupg is still trying to create the socket under my home directory...

sh$ gpg-agent -v --daemon
+ gpg-agent -v --daemon
gpg-agent[6180]: error binding socket to `/home/e/etnahouse/.gnupg/S.gpg-agent': Operation not permitted

Regards,
don

Re: New shell server transition

Posted: Tue Jun 11, 2019 11:44 pm
by yronwode
"ssh: connect to host sh.sonic.net port 22: Connection refused"

It appears to be down tonight; access has been good for weeks.

Re: New shell server transition

Posted: Wed Jun 12, 2019 8:50 am
by mike.ely
yronwode wrote:
"ssh: connect to host sh.sonic.net port 22: Connection refused"

It appears to be down tonight; access has been good for weeks.

Hi,

This was a planned outage for maintenance that eventually became an unplanned outage when the host didn't come back from a reboot.

You can always check our Sonic Status site to see about any known outages, and feel free to subscribe to our MOTD mailing list in Member Tools by going to Account / Sonic.net System Messages, and then clicking on the Subscribe button on that page.

Re: New shell server transition

Posted: Wed Jun 12, 2019 11:08 am
by scott
etnahouse wrote:
scott wrote:
scott wrote:

Ah, that is due to home directories being mounted with sshfs, which doesn't support Unix sockets. I will take a look at this, have some ideas how to fix it.

-Scott


Try it now, should be fixed.

I had to build gnupg without the option that puts the agent socket in the home directory -- it lives in /tmp. (Since each login has their own /tmp in their own chroot environments, that won't be a problem.)

-Scott


gnupg is still trying to create the socket under my home directory...

sh$ gpg-agent -v --daemon
+ gpg-agent -v --daemon
gpg-agent[6180]: error binding socket to `/home/e/etnahouse/.gnupg/S.gpg-agent': Operation not permitted

Regards,
don


Fixed.

If that happens again, you can get it to work by passing the option "--no-use-standard-socket" to gpg-agent, e.g.
gpg-agent -v --daemon --no-use-standard-socket

This is safe, since each user has their own /tmp directory, in their own chroot, on a filesystem that one can use for Unix sockets.

-Scott

Re: New shell server transition

Posted: Sun Jun 16, 2019 6:32 am
by nhdesign
Started yesterday, maybe.
Worked well most of last week, but this morning is crashed twice,
currently it responds to commands in 30 seconds to never.


Pinging sh.sonic.net [208.201.242.22] with 32 bytes of data:
Reply from 208.201.242.22: bytes=32 time=44ms TTL=52
Reply from 208.201.242.22: bytes=32 time=42ms TTL=52
Reply from 208.201.242.22: bytes=32 time=40ms TTL=52
Reply from 208.201.242.22: bytes=32 time=41ms TTL=52

Ping statistics for 208.201.242.22:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 40ms, Maximum = 44ms, Average = 41ms

Tracing route to sh.sonic.net [208.201.242.22]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms NHDESIGN [192.168.1.1]
2 2 ms 1 ms 2 ms 192.168.0.1
3 14 ms 12 ms 10 ms 10.46.64.1
4 10 ms 12 ms 11 ms bendor04dst51-bune12-27.network.tds.net [64.50.239.148]
5 170 ms 244 ms 19 ms bendor04cor51-bune451-111.network.tds.net [64.50.239.188]
6 247 ms 32 ms 23 ms sea-b2-link.telia.net [80.239.133.104]
7 212 ms 38 ms 266 ms sjo-b21-link.telia.net [62.115.118.169]
8 83 ms 39 ms 39 ms palo-b22-link.telia.net [62.115.115.216]
9 40 ms 39 ms 49 ms sonic-ic-325980-palo-b22.c.telia.net [213.248.81.255]
10 48 ms 48 ms 40 ms ae2.0.gw.equinix-sj.sonic.net [50.0.2.14]
11 43 ms 52 ms 58 ms 0.ge-1-1-3.gw.sr.sonic.net [64.142.0.197]
12 42 ms 57 ms 51 ms gig0-2.dist4-1.sr.sonic.net [208.201.224.162]
13 45 ms 49 ms 42 ms gig0-1.access4-4.sr.sonic.net [69.12.211.50]
14 44 ms 43 ms 46 ms sh.sonic.net [208.201.242.22]