216 new of 223 responses total.
Damnit Chewie
*RAAAARRRRR*
Grex was inaccessible for at least a day or so (or so it seemed) due to a UPS failure causing the server Grex exists on to reboot and then die. This lead to the dreaded "no route to host" message when trying to connect. The issue should be fixed now. Thank you, Tony!
Grex was up and down a couple times starting with last Friday and into Sunday evening. Both times it was the bug in the OpenBSD system that caused it although it is not clear if anyone has found a way to make it happen sooner. The load average was over 150 on Saturday before I lost my connection. It was not clear what was causing that sort of load and top showed a lot of 0% cpu processes. Thanks to Tony for coming to the rescue on these issues several times this weekend!
Grex went comatose again this afternoon/evening. Thanks to Tony for the reboot!
Is a reboot like a smelling salt?
It's like a smack to Otis the Drunk when Andy is having a bad hairday
What happened was we lost our network connection for a while, so Grex itself was still alive, but a reboot got it connected again after the box that was handling the network was rebooted.
(not dead yet, just *very* busy!) Can someone set up the reverse DNS for grex? Right now it's just the dynamic address that SBC is handing out. Probably seems kinda nit picky, but it really helps in e.g. IRC to see @grex.org (or @cyberspace.org, or whatever) when a user connects. I can set it up if staff doesn't have time and would like help.
I think we are going to have to wait for Tony to check in. Now that grex is a virtual machine, reverse DNS may not make sense.
Reverse DNS would be a good idea.
Okay, we had another network issue and OpenBSD decided to check out of consciousness for a while. Tony shocked it back to life again. Thank you, Tony!
Thanks Tony!
I would like to thank whoever installed Maxima on this machine. I can't install any math software on my work computer and grex has just saved the day!
Thanks for letting us know you use it! I think I installed that a while back. There are several such applications on Grex, including Octave, Maxima, FreeMat, and R. I'm glad it worked for you. An incomplete list of installed softare on Grex is available at: http://grex.org/software.xhtml
Thanks for haskell as well !
resp:16, resp:18: Unfortunately, it's not possible to get reverse DNS for grex. :( I tried to do it, but AT&T has a silly limitation where they will only give reverse DNS for a single domain name. Since it's hosted here, and I have my own stuff on my network, tonster.com trumps grex.org and arbornet.org. :) Thus, no reverse DNS. At least, no reverse DNS that makes any real sense. In other news, I just finally managed to get the SSL certificate replaced. No more warnings about how dangerous grex.org is, though I'm still not convinced that's a good thing. :)
Thanks for investigating all this, Tony. Accessing grex's web page now goes through without a hitch, as does accessing the RT help desk pages.
On the evening of Sept. 23, 2016, Grex started refusing connections. A reboot fixed the issue. Thank you, Tony!
good!
Is anybody else able to send email outside of grex? It seems that anything I try sending to the spousal unit is silently getting dropped.
Ok, update. Got this bounce. "550 Local CT IP Reputation Policy". ... <jhesse@ieee.org>: host us-smtp-2.mimecast.com[205.139.110.241] said: 550 Local CT IP Reputation Policy (Reject) - https://community.mimecast.com/docs/DOC-1369#550 (in reply to RCPT TO command) Reporting-MTA: dns; grex.org X-Postfix-Queue-ID: C545E20396B X-Postfix-Sender: rfc822; jhesse@grex.org Arrival-Date: Thu, 22 Dec 2016 11:07:47 -0500 (EST) Final-Recipient: rfc822; jhesse@ieee.org Action: failed Status: 5.0.0 Remote-MTA: dns; us-smtp-2.mimecast.com Diagnostic-Code: smtp; 550 Local CT IP Reputation Policy (Reject) - https://community.mimecast.com/docs/DOC-1369#550
Yahoo tends to bounce e-mails, maybe other ISPs. You can thank all the idiots who send spam from Grex or imitate Grex users when they send their spam from other places.
This is more than just Yahoo. The bounces I'm getting from IEEE and Slumberland indicate their outsourced MTA doesn't like our ip or something is misconfigured. (Yahoo's bounce is just kind of broken, like Yahoo in general) Is spam from grex a thing? I'm currently getting slammed by up to 200 spams a day, and all of it is from botnetted residentials or compromised Word Press installations. Finally had to set up procmail, after twenty years. (Thank you for having procmail here. Saves a lot of wear on the "d" key...)
You can run spamassassin and get rid of most of the spam. We've had users sending thousands of spam e-mails from Grex to other sites and we usually lock their accounts. But, some outside spammers spoof our user addresses and it looks to other sites like Grex is sending the e-mail when it is not. procmail also helps get rid of spam, as you note.
I did not see a Winter 2017 System Problems. Grex is currently on the Barracuda Reputations spam list. I first learned about this list yesterday when it also blocked SDF outgoing mail. I use grex to send mail to Yahoo when SDF is on the yahoo list. Grex appears not to be on the Yahoo list. An administrator should fill out a block removal form for Barracuda. Maybe they changed criteria recently.
Cross. there is user named" imabot or imamachine [dont remmber as i cant open second window t ochek. he is running some kind of botnet. just check his home directory and process that he is running
Looks like several instances of a TCP forwarder running under user imarobot, which may be owned by user huuygt77.
Hmm; doesn't seem to be running anymore. Is it doing something to harm the system?
He's running socat from his home directory. As we don't want people running bots and bouncers, he shouldn't be doing that. When he is running his little network he's using a lot more processes than the normal user, too. I'm not sure what he's trying to accomplish other than using resources.
Sure, he's using slots in the process table; but is there any realized effect on grex? If not, I don't see the harm.
`change` program menu choice C (Cflist) fails with the following messages: ".cflist" builder program version 1.0 written by "nt" File "public.txt" doesn't exist
(Repeating post from agorage conference.) Is this the appropriate place to request a new Perl module from CPAN be installed on Grex? If so, would it be possible to install Text::WikiCreole? It's for converting wiki-style markup to HTML. I'd like to play with it to build a wiki-like, but statically-generated with no CGI, site in my web page here.
Another bug report. `change` menu choice 'm' ("My finger settings ...") -->
menu choice 'f' ("Finger papa") fails with error message:
/cyberspace/bin/change_plan[68]: grexmore: not found
That should be fixed now; the script manually set $PATH and did it wrong.
bbs "Respond, pass..." prompt command "?" is broken: Respond, pass, forget, quit, or ? for more options? ? I don't understand "?" - type HELP for help
I confirm that #42 is fixed. Thanks, Dan.
Grex took an extended vacation due to problems with my ISP. AT&T was never able to determine (well, honestly, they didn't even look) the reason for the packet-loss i was getting, so they ultimately assigned a new block of IP's. Things should be returning to normal as DNS continues to propagate out.
Thanks for getting things going again, Tony!
Glad to find Grex back on-line. Missed y'all while it was down.
Ack. Not sure what happened on #49. Sorry about that. Update: Mail to Yahoo is working now. Thank you, if the fix was on this end.
Ironically, this would have fixed that issue as Grex's IP changed so Yahoo won't have blocked this one (yet).
I just performed ssl test for grex.org on ssllabs. The result is 'F', which is probably caused by old software. https://www.ssllabs.com/ssltest/analyze?d=grex.org I am looking forward for grex to improve in this area, i.e. supporting TLS best practice.
can we read your report with netscape navigator?
I recommend nobody transmit any protected health information or processes any payment cards via Grex. You've been warned.
For improving in any such area, it takes time and effort to do so. And if staff don't have time (which is quite often in the past few years), then it won't likely happen. The last time we updated the OS, a number of home-grown applications had to change significantly and it was a lot of work for staff to get things working again. Updating the OS would go a long way toward fixing any TLS issues, I'd expect, but that won't happen without a lot of staff effort.
For this to happen, a planned downtime and maintenance need to be performed. Just gather the staffs and discuss everything. Getting in touch with devio.us maintainer is also a good thing to do, since they've successfully updated their system to 5.8 without any major issue.
We'll conduct a change management review with the change advisory board in the cone of silence tunnel below our facility over by the COTS area. Those of you who have not been on the calls for this are free to dialin on our closed circuit line by the entrance. No cell phones or biomed bracelets are permitted. Bring a dixie cup of hand sanitizer.
Does not sound pretty.
downtime isn't the issue, it's for the staff to have the time to plan and execute the upgrade. I've created VM's for the new system, but we haven't had a lot of time to go beyond that stage. At some point hopefully that'll change, but right now we're just trying to keep the last remaining light on.
*sound of poopy trombones* grex% slrn -f /a/t/o/tod/.jnewsrc --create slrn 0.9.9p1 Loading /usr/local/share/slrn/slang/slrn.sl Using newsrc file /a/t/o/tod/.jnewsrc for server news.provide.net. Connecting to host news.provide.net ... Failed to resolve news.provide.net Run-Time Error slrn fatal error: Failed to initialize server.
I think I had to get a free news account outside of grex to get it to work. I don't think we can access provide.net for news any more.
See: http://dotsrc.org/usenet/ as one way to get usenet news. You need to register but I don't think costs anything.
Eternal September is popular with the kids these dats.
I was just about to say the same, accept i probably am one of the kids. :)
It takes some time to set things up, and of course, we need to (according to some) start over with just a few of standard starter items. So, we could see how it would work...Spring/Summer. We don't really have a cfadmin any more, who would normally do this.
re #62 Once upon a time I could rely on UM ITD but they removed me like Napoleon Bonaparte
Just a FYI - When logging in, the default tset command in my .profile was choking on what it was finding my terminal to be: "screen.xterm-256color". Fixed it by export TERM="vt100" in my .profile.
vt102 is better!
Looks like we upgraded to OpenBSD v6.1. I see the webserver is not running so we can't use the RT help desk, nor is our imap daemon (dovecot). bbs is operating somewhat differently (fixseen doesn't fix things completely, and there were tons of new responses that were not new. Also the scrolling is showing an entire screen for one response i.e. lots of white space). Am assuming this is all in process now and will be fixed as we go along. Knowing how much trouble our last upgrade to OpenBSD caused, I hope we can get past this one in good shape without a lot of hassle. Thanks so much for this effort to upgrade grex!
For the weird blank lines thing, add the `-c` option to your pager command line, if you are using `less`.
Oh and PS: we are definitely hitting some bugs in backtalk.
Thanks!
Yes -c fixed the issue. In fronttalk you can change your pager using the DEFINE command. DEFINE PAGER will show what you currently have for a pager. HELP DEFINE will show how to use DEFINE.
The party 5-minute-idle-boot is an annoying "feature" that the upgrade seems to have awakened.
Will we install dovecot or something similar for IMAP e-mail access? We had it running previously. I'm still not sure how the help desk is going to work if we don't have RT working on the new system. While there are ways around this, we need to let people know, and those of us doing validations and other help tasks need some way to see the requests come in and answer them.
resp:76 What five minute idle timeout? resp:77 Dovecot is installed and running.
I think I found (and fixed) the idle timeout thing.
Thank you, Dan! Upgrades are a lot work, I know.
Thanks for fixing 5-minute idle boot and first-character-swallowing problems on party.
In bbs, the pager (grexmore?) prompt "- (END)[Press space to continue, q to quit, h for help]" is being displayed and output paused before a full page of text has been printed. An extreme example is after entering r*ead at the Ok: prompt, the pager pauses and displays its prompt immediately after the command is entered before any text is displayed. Is there an environment variable or something that needs to be set to fit our actual terminal size?
Look at the page size data in `stty -a`? Is it weird looking?
42x80 looks OK
stty -a reports 80x24, which is what my PuTTY session is set to. But I see this behavior as well - sometimes it'll print a single line of text in bbs and then fire off a pager prompt.
That's weird.... To be honest, I'm actually having a hard time even visualizing quite what you guys mean. Can someone post a screen shot somewhere or something?
It's weird now...it shows how many bytes have been read until then the last Page says (END)
- (END)[Press space to continue, q to quit, h for help]
Screen shot: http://grex.org/~papa/tmp/premature-pager.png I entered "r" at the Ok: prompt to read the new messages. bbs should either print the first new message completely if the message is 42 lines or less, or print the first 42 lines and then the "...Press space to continue..." prompt. Instead, it prints the pager prompt immediately after I enter "r" without printing any message text.
Thanks, now I think I understand what you mean. I wonder if it's trying to print some kind of prefix file or something, and that file happens to be zero length.... Please give it a go now. `more` was replaced with `less`, and when you invoke `less` as `more`, it enters a compatability mode, but it's not exact.
The pager problem appears to be solved. Thanks!
Happy to do it.
My bbs already-read data was lost during the upgrade. Is it just me? Not a major problem since I can gradually re-catch-up.
emacs executable is no longer in my path. Did it move, or does it need to be reinstalled?
Try now. The installation was messed up. Due to the age and, er, vintage of the version of OpenBSD running on Grex before the upgrade, some commands were installed by hand. This caused conflicts with the package system; the result in this case was a missing symlink.
Emacs is Back and Beautiful! :)
There was a new version of emacs on the old version of Open BSD already. This one is probably the same or maybe a little newer. So it's not like we didn't have it before.
No one said we didn't. But because the previous Grex had such an old ports collection, we had to build that one from source; this caused port name conflicts with the new version from the ports collection. As a result, the /usr/local/bin/emacs ssymbolic link wasn't properly installed by the package manager.
What cross said.
As I mentioned before, my backtalk/bbs viewing history got zapped during the OS upgrade. Trying to re-catch-up on old posts has uncovered a new problem: viewing history is not being updated (or not updated correctly) for conferences other than Agora. After reading new items and responses on Agora, I can use the NEXT command to cycle through conferences in my list, but if I read the new items in a conference (which, since viewing history was lost, is all items posted since the beginning) then quit and restart bbs and again cycle through my conference list with NEXT, the same conferences come up again showing new items, but their the same items as I previously read. Does that make any sense?
Nice pager fix, Dan!
resp:100 Not exactly, but try the "fixseen" command.
So, since yesterday I'm not getting any new mail, with these errors in my procmail logfile: procmail: Lock failure on "/var/mail/jhesse.lock" procmail: Error while writing to "/var/mail/jhesse" From jhesse@fastmail.net Thu Jun 1 14:14:27 2017 Subject: testfoo Folder: **Bounced** My mail client sees nothing over imap. (No old or new mail) elm works as normal, though. Do I need to change something?
Maybe related to jhesse's problem, yesterday I checked my Grex mail box for the first time since the upgrade and was greeted with the message "Can't open folder /var/mail/papa: no such folder" instead of the usual "0 messages in inbox".
Mail is now delivered into your home directory; so your mail spool file is in ~/Mailbox. If you're sourcing the global dot files, you should get an environmnet variable that tells mail programs and the like where to find your mail.
resp:103 Oh sorry; missed this earlier today. As as resp:105. If you're setting $MAIL, then unset it; modify your .procmailrc accordingly.
Thanks! .procmailrc is fixed, so I can get mail again through elm. IMAP and POP still not working, though. My mail client says it can connect to both and I'm not seeing anything contrary in the logs. The server daemon is dovecot, correct? I don't know enough to know the configuration.
Yes, IMAP is a problem now. It doesn't seem to know to look in our home directory for the Mailbox file. I suspect this requires a bit of tweaking of the dovecot config, but it is do-able.
Funny... I updated the dovecot config the other day. It should work. I'm out of town at the moment, but will try and see about it if I can login.
Thanks, Dan!
Ahhh..found it. The dovecot config file moved from the last version on Grex until now. I've updated the correct version. It should work again.
Thank you again. Everything seems to be working.
Agree. I'm receiving and sending e-mail now. Just took a few tweaks to my setup (.login, .tcshrc, and .procmailrc).
Something is quirky... 1 newresponse item First item 1, last 140 Browse (item list), Read (new items), Join confname (type "help conf" for a list of conferences), Help (for more help), pine (for e-mail) or Quit (to exit from Picospan). Ok: r No items found in range Browse (item list), Read (new items), Join confname (type "help conf" for a list of conferences), Help (for more help), pine (for e-mail) or Quit (to exit from Picospan).
tod's problem has been happening a lot since the OS upgrade. The whole fronttalk bookmark system has been wonky. Before the upgrade I had paged through the backlog in every conference. After the OS upgrade I found my conference bookmarks all reset. But now if I read through the backlog on a conference, then check the conference again later, the new item and response numbers aren't changed.
P.S. The new items filter on the web interface works fine.
resp:114 I'm seeing that, too.
Does "fixseen" or "fix" repair it per cf?
Not really. I'm not sure what's up with it; I rather suspect a bug in backtalk.
I can't resolve reddit.com and news.ycombinator.com dns address. Is this a temporary error or intended behavior?
Certainly not intended. I just checked and both resolved for me....
reddit.com didn't resolve for me from lynx. But yahoo.com did. Maybe it was a slight internet glitch.
Didn't resolve or didn't connect?
"Unable to connect to remote host"
That's rather different. :-)
It does resolve okay, then just doesn't connect. I don't use reddit.com anyway, so it doesn't bother me. Other sites do connect.
Weird. Observe: : grex; host reddit.com reddit.com has address 151.101.65.140 reddit.com has address 151.101.193.140 reddit.com has address 151.101.129.140 reddit.com has address 151.101.1.140 reddit.com mail is handled by 1 aspmx.l.google.com. reddit.com mail is handled by 10 aspmx2.googlemail.com. reddit.com mail is handled by 10 aspmx3.googlemail.com. reddit.com mail is handled by 5 alt1.aspmx.l.google.com. reddit.com mail is handled by 5 alt2.aspmx.l.google.com. : grex; ping reddit.com ping: no address associated with name : grex; ping 151.101.65.140 PING 151.101.65.140 (151.101.65.140): 56 data bytes 64 bytes from 151.101.65.140: icmp_seq=0 ttl=56 time=26.270 ms 64 bytes from 151.101.65.140: icmp_seq=1 ttl=56 time=26.722 ms 64 bytes from 151.101.65.140: icmp_seq=2 ttl=56 time=26.755 ms ^C --- 151.101.65.140 ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 26.270/26.582/26.755/0.221 ms : grex; I cn't see any rational reason why ping would complain about address translation for reddit.com. But wait: : grex; host -v reddit.com Trying "reddit.com" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63255 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;reddit.com. IN A ;; ANSWER SECTION: reddit.com. 101 IN A 151.101.65.140 reddit.com. 101 IN A 151.101.129.140 reddit.com. 101 IN A 151.101.1.140 reddit.com. 101 IN A 151.101.193.140 Received 92 bytes from 8.8.8.8#53 in 41 ms Trying "reddit.com" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33781 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;reddit.com. IN AAAA ;; AUTHORITY SECTION: reddit.com. 466 IN SOA ns-557.awsdns-05.net. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400 Received 109 bytes from 8.8.8.8#53 in 38 ms Trying "reddit.com" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23449 ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;reddit.com. IN MX ;; ANSWER SECTION: reddit.com. 71 IN MX 1 aspmx.l.google.com. reddit.com. 71 IN MX 10 aspmx2.googlemail.com. reddit.com. 71 IN MX 10 aspmx3.googlemail.com. reddit.com. 71 IN MX 5 alt1.aspmx.l.google.com. reddit.com. 71 IN MX 5 alt2.aspmx.l.google.com. Received 158 bytes from 8.8.8.8#53 in 41 ms : grex; Meanwhile, : grex; dig reddit.com ; <<>> DiG 9.4.2-P2 <<>> reddit.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 41600 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;reddit.com. IN A ;; Query time: 40 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Jun 13 11:10:15 2017 ;; MSG SIZE rcvd: 28 : grex; So it would seem that unbound running on Grex isn't happy returning results for reddit.com. Weird.
bash is my default shell and in my .bashrc I add the directories ~/man and ~/share/man to my MANPATH variable. If I echo $MANPATH, the tilda in the paths is correctly expanded to /p/a/papa, but if I run man or apropos for an unknown command, the error message indicates the programs are searching my old home directory /u/p/a/papa.
Re: 127, thanks. Yeah it was a bit weird.
resp:128 That's actually correct. /p is a symbolic link to /u/p (don't ask why...filesystem limitations). So /p/a/papa is /u/p/a/papa; the error message must expand out the readlink() results into the pathname (or rather, the commands that generate the error message do that).
OK. No worries then.
It's almost like having two home directories, but not.
Regarding local dns resolution for reddit.com, it seems that grex local dns doesn't cache reddit.com address. Resolving through google dns works fine. Does grex local dns server resolve the name through upstream resolver or recursively querying root servers?
After viewing /etc/resolv.conf and /var/unbound/etc/unbound.conf it seems that grex uses both local resolver and google dns servers. I suggest removing google dns entries in /etc/resolv.conf and enabling dns forwarding in the unbound.conf forward-zone: name: "." forward-addr: 8.8.8.8 forward-addr: 8.8.4.4 forward-first: yes Enabling forward-zone should give better dns resolving capability in the applications and makes better unbound dns caching for subsequents dns lookup.
That sounds like a reasonable approach; I'll go ahead and implement it.
Setting unbound to forward to the Google DNS servers seems to work. Given that name servers in /etc/resolv.conf are checked in order, I don't see a reason to remove 8.8.8.8 or 8.8.4.4; if unbound ever crashes for whatever peculiar reason, they'll continue to work.
I am unable to send mail to grex. ----- Transcript of session follows ----- ... while talking to grex.org.: >>> DATA <<< 554 5.7.1 Service unavailable; Client host [205.166.94.20] blocked using multi.uribl.com; 127.0.0.1 -> Query Refused. See http://uribl.com/refused.shtml for more information [Your DNS IP: 173.194.94.133] 554 5.0.0 Service unavailable <<< 554 5.5.1 Error: no valid recipients Reading the referred page, I see: > If an email you sent bounced, and included a link to this page, then > it was rejected because the receiver has not implemented URIBL lookups > correctly. Please note that I don't use grex as my mail mailserver; however this still seems like a system problem that should be reported.
PS. Further, I read on the above-mentioned page: > Possibly changing your nameservers from a public dns provider (ie > opendns/google) to your local ISP may solve it. Is this issue a result of the recent DNS changes discussed above?
The downside of using dns forwarding to public dns server is uribl will prevent sending mails to grex. There is an alternative to solve the issue. Instead of using dns forwarding, add an updated root-hint file so that the dns resolver will query root-servers and prevent dns blacklisting on grex. Unbound has built-in root-hint, but it's often outdated. The updated root-hint file can be obtained from https://www.iana.org/domains/root/files The unbound.conf needs to be updated to include root-hints: /path/to/updated/root-hint
Perhaps I'm missing something, but it seems like not forwarding to the public servers puts us back into the same boat with e.g. reddit that we made this change to get out of in the first place. Am I missing something here?
Re: #138: Got the same bounce on a test message. No new emails since Monday.
Try again: I've reset Grex's DNS configuration to be substantially similar to what it was before.
Actually, uribl.com wasn't happy at the rate of queries directly from Grex, either, so I've disabled it. Sadly, this will allow more spam through; but it will also allow real mail in, too. unbound is now forwarding to 8.8.8.8 and 8.8.4.4 again, so resolving 'reddit.com' works again.
Here's what I'm getting with RT now: "RT has detected a possible cross-site request forgery for this request, because the Referrer header supplied by your browser (www.grex.org:443) is not allowed by RT's configured hostname (grex.org:443). A malicious attacker may be trying to update a ticket on your behalf. If you did not initiate this request, then you should alert your security team." Then you have to click a link to continue. I have to do this a couple times to respond to a ticket. This started after the most recent changes to the dns, etc. Is there some way to fix RT so it doesn't do this and lets me respond to tickets easily like it used to? Looks like it might be the difference between www.grex.org and just grex.org.
Hmm. Are you connecting to https://www.grex.org/ or https://grex.org? You should always use the latter.
I'm connecting to https://grex.org/. If the browser adds "www." I don't see it.
Hmm. That's weird; I can't seem to reproduce it....
For redirecting www.grex.org to grex.org, I think a http server rewrite rule is sufficient.
I mean, the http server need to give 301 response when
a GET request to www.grex.org performed, redirecting
the request to correct domain.
Here is nginx configuration snippet to do that.
server {
server_name www.grex.org;
return 301 $scheme://example.org$request_uri;
}
resp:144: feel free to use 99.95.107.130, 45.33.105.232, and 45.79.186.112 for DNS forwards. They're my caching nameservers and are already configured to allow queries from my block.
Obviously, grex was unavailable for several days this past week. There was a network hardware issue and it took a while to get hardware replaced and hooked back up. I just got to grex via grex.org, so that is working again. cyberspace.org works okay, too. New IP is 75.61.90.157. DNS is catching up with this change and most everything should be working now, or will be soon. Thanks to Tony for getting us going again!
Thanks
Grex was offline for a while in the last couple days. This was due to the huge ice storm that came through and knocked out the electricity in a lot of areas around here. Where I'm at the electricity was off for 4 hours, which is more than enough for most UPSes to run out of energy to keep things going. Tony was able to successfully booted again. Thank you, Tony!
resp:154 Glad Grex is back up. Thank you Tony and Kent.
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.
resp:156 What exactly is not working? Any error messages?
Right now, it is a case of Firefox can't connect, but earlier it said to contact the administrator (and that was all).
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....
It's working for me now. Thanks!
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.
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.
Email was moved to your home directory and is no longer in /var/mail.
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....
Thanks, tonster. Condolences on the graphics card.
re #164 What was the STB? (Roku?) Thanks for getting it back online
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.
re #167 Zoinks. Must have been right in your backyard
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.
ssl certificates should now auto-renew as well, and restart nginx when it does...we'll see in December!
Yee hah! letsencrypt ...i have higher hopes than Thawte
Thanks for fixing up the ssl certs, Tony. That will help a lot.
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.
Grex is futuristic
Retro-futuristic
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.
Wouldn't surprise me if I needed to correct the time on the hypervisor. I'll have to take a look sometime.
User 'romania' is running psybnc for a while now.
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.
re #179 The copper key cannot be obtained without a vulcan mind meld with m-net
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
re #181 https://www.courthousenews.com/ex-newsweek-owners-arraigned-on-10m-fraud/
We have to trust the just judges will prevail against the injustices of the world.
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.
That's good news. Thanks for looking into this.
:)
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.
Thanks for getting Grex back on-line, Tony. I know it must take a lot of time and frustration.
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!
resp:189 Yes, big thanks to Tony. Long live Grex!
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.
I was able to log in on the RT web application yesterday and do some clean up. So it appears to be working now.
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).
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?
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.
I have mostly CentOS VMs. Good job, Tony
resp:195 Thanks for explaining Grex's current configuration, Tony.
#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.
re #198 It's all the same, imo. I am nostalgic about yum, tho
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.
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?
resp:201 Probably because you didn't set the $MAIL environment variable to $HOME/Mailbox ?
mutt vs alpine discuss
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.
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?
..not that we even have an outgoing smtp server that I can see.
re #204 Agreed about mutt
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.
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.
MM is like a fine wine and requires a VT52 for full appreciation.
resp:205 `export MAIL=$HOME/Mailbox`
re#211 thanks! How can I validate my account?
#200, cross, what would Grex use instead of OpenBSD?
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).
resp:213 Probably FreeBSD.
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.
resp:216 I've posted more details on the trouble here: item:garage:60
Thanks, papa.
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.
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.
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.
re #221 Very tidy, indeed. Thanks for the rundown!
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.
You have several choices: