Grex General Conference

Item 4: Grex System Problems - Fall 2015/Winter 2016

Entered by cfadm on Thu Dec 31 16:42:13 2015:

68 new of 223 responses total.


#156 of 223 by kentn on Fri Apr 20 21:17:51 2018:

There have been some reports of connection and application issues since
we brought Grex back up.  The web site and ssh should be working again
and so should mutt and mc.  The RT help desk app doesn't seem to be
working right now so I'm unable to reply to validation and help requests
even though I can, when I find the time, work on them.  


#157 of 223 by cross on Fri Apr 20 23:13:00 2018:

resp:156 What exactly is not working? Any error messages?


#158 of 223 by kentn on Fri Apr 20 23:43:42 2018:

Right now, it is a case of Firefox can't connect, but earlier it said
to contact the administrator (and that was all).


#159 of 223 by cross on Sat Apr 21 01:54:18 2018:

Hmm. It seems some file permissions were wrong; probably due to
me upgrading the web server. Are you still having problems? I'm
able to get into RT, but didn't try to do anything....


#160 of 223 by kentn on Sat Apr 21 14:39:01 2018:

It's working for me now.  Thanks!


#161 of 223 by kentn on Tue May 29 19:51:35 2018:

E-mail may not be working for you if it requires a SSL certificate to
be up to date.  Grex's SSL certs expired today and that seems to be one
reason.  Another reason is that grex tends to be blacklisted on some
popular sites including gmail. My iphone was complaining about every
15 seconds that grex.org was not verified and it said the SSL cert had
expired.



#162 of 223 by glitch on Tue Jun 5 20:58:43 2018:

SSH is quite laggy, I'm logged in to a handful of other systems for work and
have no issues there, so I'm pretty sure it's not me.

Seems that the SSL cert has expired for Backtalk. Since we're on OpenBSD 6.3
here, we've got acmetool (a client for LetsEncrypt) right in the base OS --
not only are the certs free, but the update process can (and should!) be
automated with a cron job or /etc/daily.local entry. Ping me for help, I run
OpenBSD servers for $day_job :)

Finally, it seems /var/mail/glitch is gone and I can't get email here at the
moment.


#163 of 223 by kentn on Thu Jun 14 02:13:50 2018:

Email was moved to your home directory and is no longer in /var/mail.


#164 of 223 by tonster on Thu Sep 6 07:32:39 2018:

We should definitely setup letsencrypt for our ssl certs. I think I
started looking into it and then got busy with my own $day_job. :) 

In other news, we were offline for the better part of 3 days due to a
storm on Monday. Multiple lightning strikes were reported by my
equipment, the closest being 0.3 miles away. It took out my internet
router, a video card, one of my STB's and caused some really weird shit
with multiple other computer components on my network. AT&T came out
this evening and got the internet back online. The graphics card for my
main pc was the biggest issue for me. :( Luckily I'll get that
Friday...but in the meantime, Grex is back....


#165 of 223 by papa on Thu Sep 6 09:24:22 2018:

Thanks, tonster. Condolences on the graphics card.


#166 of 223 by tod on Thu Sep 6 17:41:13 2018:

re #164
What was the STB? (Roku?)
Thanks for getting it back online


#167 of 223 by tonster on Fri Sep 7 07:39:34 2018:

resp:166: U-Verse receivers. My Roku devices are all still working fine.
I was rather surprised to see the U-Verse receiver dead. My network gear
all had to be rebooted after the strike, as they weren't passing
traffic. One of the switches I had to reboot twice before it finally
started working properly. All in all really weird shit I haven't seen in
storms up to now. All of the equipment was behind UPS' too, although I
suspect the surge that took out the AT&T RG probably came through the
phone line which is unprotected.


#168 of 223 by tod on Sat Sep 8 01:10:15 2018:

re #167
Zoinks.  Must have been right in your backyard


#169 of 223 by tonster on Tue Sep 18 13:04:53 2018:

resp:168: Indeed. Annoying how much equipment I've lost this summer! I'm
still upset at having the UPS taken out a couple months ago. :(

I've now configured acme-client on grex and enabled/installed an SSL
certificate from letsencrypt. Still need to automate this so that it
renews automatically every 3 months, but at least it's now as simple as
running acme-client to generate a new ssl certificate, and then restart
nginx.


#170 of 223 by tonster on Tue Sep 18 13:19:55 2018:

ssl certificates should now auto-renew as well, and restart nginx when
it does...we'll see in December!


#171 of 223 by tod on Wed Sep 19 03:48:11 2018:

Yee hah!
letsencrypt ...i have higher hopes than Thawte


#172 of 223 by kentn on Thu Sep 20 03:00:38 2018:

Thanks for fixing up the ssl certs, Tony.  That will help a lot.


#173 of 223 by kentn on Thu Nov 1 21:55:04 2018:

Time on Grex is almost 2 hours off.  It's not the TZ setting we use.
For some reason the clock has wandered.  Perhaps ntpd stopped running
or never got restarted?  Or maybe a reboot knocked the clock out of
whack.


#174 of 223 by tod on Mon Nov 5 22:17:43 2018:

Grex is futuristic


#175 of 223 by papa on Mon Nov 5 22:40:36 2018:

Retro-futuristic


#176 of 223 by cross on Mon Nov 5 22:48:13 2018:

Interesting.  Thanks for the report; I sync'ed it manually
(doas rdate -n pool.ntp.org) and it's now sync'ed as a
stratum 3 server.

I've found that the NTP server in OpenBSD tends to drift
occasionally, sometimes substantially; particularly on a
virtualized machine.


#177 of 223 by tonster on Wed Nov 14 14:32:39 2018:

Wouldn't surprise me if I needed to correct the time on the hypervisor.
I'll have to take a look sometime.


#178 of 223 by ryan on Mon Nov 19 19:47:18 2018:

User 'romania' is running psybnc for a while now.



#179 of 223 by walkman on Mon Dec 10 22:31:55 2018:

In order to adjust the Grex time module, an OASIS avatar must defeat
Acererak the Demi-Lich in a best-of-three match of Joust.


#180 of 223 by tod on Wed Dec 12 15:18:35 2018:

re #179
The copper key cannot be obtained without a vulcan mind meld with m-net


#181 of 223 by walkman on Fri Dec 14 17:07:33 2018:

re #180 
I did the vulcan mind meld with arbornet and it told me that the deep
state often white-washes real crimes from cabal allies.
https://www.newsweek.com/what-fbi-found-emails-anthony-weiner-laptop-5176
52


#182 of 223 by tod on Fri Dec 14 23:29:35 2018:

re #181
https://www.courthousenews.com/ex-newsweek-owners-arraigned-on-10m-fraud/


#183 of 223 by mijk on Thu Dec 27 20:44:10 2018:

We have to trust the just judges will prevail against the injustices of the
world.


#184 of 223 by tonster on Sun Dec 30 18:22:08 2018:

Looks like my script to auto-renew ssl certs worked in that it did
automatically renew (in November), but I had used a different filename
than the one that was created when it was renewed, so when it bounced
nginx it didn't pick up the new cert. I changed the nginx config to
reference the correct file, so in Jan when it renews it should work as
intended.


#185 of 223 by kentn on Mon Dec 31 13:35:41 2018:

That's good news. Thanks for looking into this.


#186 of 223 by tod on Mon Dec 31 22:00:57 2018:

 :)


#187 of 223 by tonster on Mon Apr 15 12:45:10 2019:

Looks like my script is now working again. It renewed automatically
about a month ago. 

Grex has been recently unavailable due to another bad modem. I had a
power outage about 2 weeks ago, which I believe likely contributed
to/caused this. Wednesday I called in to schedule a service tech and
they attempted to update the firmware to resolve it. It worked for an
hour or so after that, at which point the modem bricked. It came back
online Friday evening but for some reason nginx wouldn't serve pages (or
some other OS issue was blocking requests). I rebooted this morning and
things seem fine now.


#188 of 223 by papa on Mon Apr 15 13:28:26 2019:

Thanks for getting Grex back on-line, Tony. I know it must take a lot of time
and frustration.


#189 of 223 by kentn on Mon Oct 7 01:25:05 2019:

Okay, so Grex was out of commission for several days last week.  I'm told
it was due to a power outage, which I can believe given all the storms
and outages we've had in SE Michigan this year.  Thanks to Tony for getting
it all back up and running again!


#190 of 223 by papa on Mon Oct 7 13:14:26 2019:

resp:189 Yes, big thanks to Tony. Long live Grex!


#191 of 223 by kentn on Thu Oct 10 02:14:08 2019:

One thing that is not currently working is our RT help desk web
application.  At least when I try to access it, it never loads the page
and times out.  So, something isn't quite right there yet.  It seems
the other parts of RT are working, such as assigning ticket numbers.

Thus, while I still get help desk e-mails and can act on them (such as
do password resets and validations), I can't respond except through a
personal account. I'd rather not do that.


#192 of 223 by kentn on Tue Oct 15 12:25:04 2019:

I was able to log in on the RT web application yesterday and do some
clean up.  So it appears to be working now.   


#193 of 223 by kentn on Sat Feb 22 01:38:05 2020:

Okay, you probably noticed that grex was not found for a few weeks.
This is something going on with some hardware and Tony finally had the
time to look into it.  Thanks, Tony!

Not sure what we could've done.  Hardware sometimes causes issues, and
like most of us, the time to look into might be enough to getting done
it up immediately. We have been lucky that Tony has been able to give
Grex a home for years.  So please thank Tony for looking into it!

Welcome back, Grex!

(I had 87 emails when I logged in, so it must have been doing something
part of the time, we just couldn't access it).


#194 of 223 by papa on Sun Feb 23 23:35:25 2020:

Thank you, Tony! Glad to have Grex back!

And also thanks to Tony for all the unsung work he has done for years keeping
Grex running. Does Grex collect enough donations that running the server is
at least not a financial burden?



#195 of 223 by tonster on Fri Feb 28 22:00:03 2020:

The grex hardware was virtualized several years back when it failed the
last time, so it now runs on a VMware server with many other machines I
use for work. So it's really not a financial burden on me, as I'd have
the hardware either way. Having it virtualized, though, does present
somewhat of a challenge as hosting it elsewhere would involve some
complexities. We've discussed a bit about finding a hosted solution, but
bsd (any dirivitive, but openbsd I've never seen) is a very uncommon
supported virtualization OS.


#196 of 223 by tod on Sun Mar 1 01:06:32 2020:

I have mostly CentOS VMs.
Good job, Tony


#197 of 223 by papa on Sun Mar 1 05:04:06 2020:

resp:195 Thanks for explaining Grex's current configuration, Tony.


#198 of 223 by walkman on Mon Mar 2 17:40:31 2020:

#196 How do you like using yum and RPM vs apt-get? I have been using 
Ubuntu for 15 years? I am curious about jumping ship for something new. 


#199 of 223 by tod on Mon Mar 2 18:20:09 2020:

re #198
It's all the same, imo.  I am nostalgic about yum, tho


#200 of 223 by cross on Tue Mar 10 17:56:57 2020:

resp:195 There are hosting providers out there.  For instance,
I'm running some OpenBSD VMs on both Vultr and Digital Island.
But hopefully we'll ditch OpenBSD when moving Grex into the
cloud.  The issue is just time and, frankly, money.


#201 of 223 by lar on Tue Mar 10 22:29:21 2020:

Why does alpine 2.21 give an error "can't open folder /var/mail/lar :
no such folder BUT alpine 2.21 opens my mail fine when accessed from the menu
shell?


#202 of 223 by cross on Wed Mar 11 12:56:45 2020:

resp:201 Probably because you didn't set the $MAIL
environment variable to $HOME/Mailbox ?


#203 of 223 by tod on Wed Mar 11 13:31:15 2020:

mutt vs alpine
discuss


#204 of 223 by papa on Wed Mar 11 22:31:28 2020:

resp:203 On principle, I prefer mutt because it is structurally simpler and
more straight-forward. alpine's menus and on-screen help are a distraction
and waste of space. However, for some reason I have ended up using alpine on
Grex.


#205 of 223 by lar on Thu Mar 12 11:14:14 2020:

re#202
Hi cross,
What is the syntax for that? I was running the C shell (tcsh) and tried 
using the "setenv" command. I have switched shells over to what you are 
using now (bash) How would I do it in that?


#206 of 223 by lar on Thu Mar 12 11:15:09 2020:

..not that we even have an outgoing smtp server that I can see.


#207 of 223 by tod on Thu Mar 12 20:30:34 2020:

re #204
Agreed about mutt


#208 of 223 by kentn on Fri Mar 13 02:12:10 2020:

I've used mh, nmh, pine, alpine, and now mutt. Mutt isn't hard to learn and
seems to work okay for me so I've stuck with it.


#209 of 223 by cunnings on Fri Mar 13 03:01:25 2020:

I like alpine and use in almost everywhere. The menus aren't a distraction,
I operate efficiently via muscle memory. IMO it's easier to navigate through
my many folders dedicated to various email lists, and setting up new filters
is easy using the setup menu. I've used mutt in the past, it's ok, and I like
the vim-like key bindings. MM on TOPS-20 is nice too.


#210 of 223 by tod on Fri Mar 13 04:40:39 2020:

MM is like a fine wine and requires a VT52 for full appreciation.


#211 of 223 by cross on Thu Mar 19 16:57:03 2020:

resp:205 `export MAIL=$HOME/Mailbox`


#212 of 223 by lar on Tue Mar 24 02:06:14 2020:

re#211 
thanks!

How can I validate my account? 


#213 of 223 by tfurrows on Tue Mar 24 18:49:57 2020:

#200, cross, what would Grex use instead of OpenBSD?


#214 of 223 by kentn on Tue Mar 24 19:14:12 2020:

Re 212:  I think you might mean "verify" your account.  Your account is
already validated.  To verify an account on Grex, you need to provide
acceptable identification.  This can, for example, be a copy of a
state-issued valid ID like a driver's license or by using a validated
PayPal account to purchase a minimal membership (e.g. $1).  Validated
PayPal accounts are determined by PayPal.  As you might expect that
generally means they know your real identity and there is a bank account
or credit card connected with the PayPal account.  Since verified users
have more access to the internet, verification allows Grex to identify
people who cause problems, if an agency, like the FBI, come calling (and
believe me they have contactd grex before about particular users).


#215 of 223 by cross on Wed Mar 25 18:47:28 2020:

resp:213 Probably FreeBSD.


#216 of 223 by kentn on Sat Nov 14 22:58:12 2020:

I noted today that one of my computers wouldn't connect to grex via
ssh while another would.  They are different versions of FreeBSD (11.4
worked, 12.1 didn't). Same setups of ssh_config.

Anyway changing the MTU for 12.1 fixed it, which is a bit weird.  I had
to edit /etc/dhclient.conf and supersede the interface-mtu setting that
normally is set to 1500 by DHCP and setting it to 1400 helped.  Probably
this is due to the ciphers that get picked in the ssh connection.
Each computer picks a different one (using the same setup).  So more
investigations to do.

I had noted someone else had seen something similar in the past couple
weeks.


#217 of 223 by papa on Mon Nov 16 00:02:46 2020:

resp:216

I've posted more details on the trouble here: item:garage:60


#218 of 223 by kentn on Mon Nov 16 01:49:10 2020:

Thanks, papa.


#219 of 223 by tonster on Mon Nov 16 19:04:42 2020:

My guess is that it might have to do with the method now used for
accessing Grex. I recently canceled my AT&T service, which allowed me to
have static IP's at home. With that now gone, I've established a VPN
between my servers in Azure and home, and am routing grex (and m-net)
via static IP's I've got in Azure and home over that VPN tunnel. Exactly
why this is working without incident for some ssh clients and not others
I'm unsure, but that is the change that was made in the past week when
this started.


#220 of 223 by tod on Wed Nov 18 02:18:47 2020:

re #219
This is excellent - curious how that is setup.
I have a nat behind a nat at my office and want the pi there available
for sshd from home and elsewhere.  Not sure how to go about it.


#221 of 223 by tonster on Sat Dec 5 22:10:28 2020:

resp:220: What I did was created a vm at home to route the tunnel, and
established a strongswan tunnel between the two sites. I then created an
iptables rule to create a route to my network via the tunnel:

-A POSTROUTING -s 10.0.0.0/24 -d 192.168.0.0/20 -j MASQUERADE

and the opposite on the other end of the tunnel:

-A POSTROUTING -s 192.168.0.0/20 -d 10.0.0.0/24  -j MASQUERADE

For the Azure side, I also route the additional bound IP's over the
tunnel back home via:

-A PREROUTING -d 10.0.0.9/32 -j DNAT --to-destination 192.168.0.110
-A POSTROUTING -d 192.168.0.110/32 -j SNAT --to-source 10.0.0.9

strongswan starts on boot, and I've put the iptables rules in the
appropriate file for the OS (ubuntu/centos), so everything comes up on
boot and strongswan monitors the tunnel so it automatically restarts
should it drop. It ended up working out quite well, and it was much
easier to get it running than I'd expected.


#222 of 223 by tod on Sat Dec 12 05:40:45 2020:

re #221
Very tidy, indeed.  Thanks for the rundown!


#223 of 223 by kentn on Tue Feb 21 16:19:26 2023:

The machine grex is running on had more disk space added yesterday. That
took it offline and made it appear the SSH security info had changed.
It's back up now and everything should be back the way it was before the
changes.  Thanks go to Tony for keeping grex going.


There are no more items selected.

You have several choices: