updateDNS.sh on sa-vm1.apache.org - DNS updates disabled
3.3.3.updates (TXT) -> \"1815188\" File /usr/local/bin/updateDNS.disabled exists, not updating DNS.
Re: Fwd: Re: apachesf account at Sonic
On 11/14/2017 8:07 AM, Dave Jones wrote: What do we think they will be hosting? My masscheck server at ENA is providing about 77% of the current masscheck corpus (we really need other contributors) and it is an 8 core a 8 GB RAM VM. It really only needs that much RAM and cores for the masscheck processing. If they setup a masscheck'er, do we have any idea of their corpus size? This will greatly determine the specs it needs. A dual-core, 4 GB might be OK if their corpus is small. I am not familiar with what it takes to run the "trap." What is that doing exactly? Are you hosting that on PCCC servers today? Are they going to host an SA mirror too? I can give them bandwidth estimates once we get the sa-updates rolling again. I personally would prefer CentOS if we are going to be running it but I would be OK with Ubuntu if we need to consider consistency with the sa-vm1.apache.org box. IPMI would be great so we wouldn't have to bother them if something is hung and we need to power cycle it. They are going to give us a physical box. I'll ask for an 8core/8GB box and ask if it is ok to do trap data, masscheck and run a mirror. I do not know if the trap data is usable for masscheck. I think it's automated and spam only.- We've never had a power cycle issue and we have access to their normal support to bounce if ever needed. I'll ask for current CentOS. Thanks, KAM
Re: Is the rsync OK?
On 11/14/2017 2:26 AM, John Hardin wrote: On Tue, 14 Nov 2017, Jari Fredriksson wrote: but it still asks for the password. It sounds like your SSH public/private key setup has broken. Ensure that your private key is still available at your end. Try ssh to the rsync box and verify that the public side is still setup properly. "ssh -v" should tell you pretty quickly whether the PK cert is being attempted and if so whether it's succeeding or falling back to interactive password auth. It's possible that the cert algo is no longer being accepted by the server. I recently (a year or so back) upgraded my ssh servers and found that some of my old private keys were no longer being accepted because DSA was deprecated (IIRC) and I had to generate new ones. Have to admit I'm confused. Off the cuff I was wondering if something with the rsyncd.conf changed. I don't think we are using certs or SSH and don't understand your post. Regards, KAM
Re: 72_scores.cf compared to the one from march 15
> On 11/14/2017 07:28 AM, Merijn van den Kroonenberg wrote: Hi, When I compare the current 72_scores.cf with the one from march 15 I can see we are getting closer and closer. The march one has 144 lines and the current one has 108. >> Actually, personally I think below issue should be addressed before >> going >> live with the new score generation. Without it there still is a too big >> of >> a difference and I would not feel confident that some major issue is not >> lurking below this. I understand you want to go live sooner rather than >> later, but well these are my thoughts :) > > Last night's issue was my goof. Yesterday's 72_scores.cf was much > closer to March's size. It has been hovering around 103 line for some time now. But still it used to be 140-160 lines. > > Keep in mind that the size of the 72_scores.cf has fluctuated over the > years so we aren't sure that it has to be the same number of lines that > it was back in March to be correct now. If you know something is still > broken with the 72_scores.cf we can hold off and get it corrected. Do > you know of anything we need to address still? Yes, thats why I do not only look at the amount of lines, but also do checks on which lines are missing (or new) and why. In the part below (which you cut off in this mail, but was still in my previous mail) I found another change in the "dos" lock-scores which is not in the actually used lock-scores. It is similar to what happend to the merge-scores script. I think with this fixed the 72_scores.cf will look much more like the march one, so its much easier for me to check and explain any remaining differences. So then I could see if suspicious rules are missing or added. > > I have installed yesterday's ruleset manually on my SA platforms and > will check the scoring levels today and tomorrow. > > Dave > Due to the way I debug and solve problems I need to theorize them instead of just testing. Thats why I really would like to have lock-scores fixed.
Re: Access to rsync.spamassassin.org
On 11/11/2017 05:08 AM, Sidney Markowitz wrote: It's been a while since I had a request from someone to give the an rsync account. When I tried to ssh to rsync.spamassassin.org (after dealing with the hos key changing) using my apache.org ssh key (which still works on minotaur as a check) I get "LDAP authorisation check failed". Does something have to be done to get my access back after changes we've made? Thanks, Sidney Did you get in OK? I have been traveling the past few days. Didn't mean to ignore your email above. I see you logged in recently so you may be OK now and fixed your own rsync password issue. root@sa-vm1:~# last davej pts/0 XXX.XXX.152.81 Tue Nov 14 12:32 still logged in sidney pts/0 XXX.XXX.193.155 Tue Nov 14 05:48 - 05:57 (00:08) kmcgrail pts/0 XXX.XXX.131.234 Tue Nov 14 03:16 - 03:21 (00:05) Dave
Re: sa-update issue follow-up
On 11/13/2017 08:21 PM, Kevin A. McGrail wrote: OK, so following up my last email, it appears all old updates were gone too. I have only 57 update files. These are release artifacts and need to be put back. Apologies if I said to move them but people are using them it appears. I think I found them in an archives dir and I created a files_moved_back.txt and moved them back so mirrors will sync them again. I'm guessing someone was trying to clean things up. That fixed errors like http://www.sa-update.pccc.com/1786640.tar.gz not found. Did the 1799552 update get removed but DNS left? I grabbed them from my backups and restored them. It looked like they were from september and then modified this morning at 10AM or so. Perhaps just an accident? Regards,KAM I see you moved all of the files from the archived subdir back into the main updates location so they would rsync out to all of the mirrors. That's fine. I have removed the archived subdir since it's no longer needed. Dave
updateDNS.sh on sa-vm1.apache.org - DNS updates disabled
1.3.3.updates (TXT) -> \"1815211\" File /usr/local/bin/updateDNS.disabled exists, not updating DNS.
updateDNS.sh on sa-vm1.apache.org - DNS updates disabled
0.3.3.updates (TXT) -> \"1815211\" File /usr/local/bin/updateDNS.disabled exists, not updating DNS.
updateDNS.sh on sa-vm1.apache.org - DNS updates disabled
2.3.3.updates (TXT) -> \"1815211\" File /usr/local/bin/updateDNS.disabled exists, not updating DNS.
updateDNS.sh on sa-vm1.apache.org - DNS updates disabled
3.3.3.updates (TXT) -> \"1815211\" File /usr/local/bin/updateDNS.disabled exists, not updating DNS.
Re: Cron <automc@sa-vm1> ~/svn/trunk/build/mkupdates/run_nightly | /usr/bin/tee /var/www/automc.spamassassin.org/mkupdates/mkupdates.txt
On 11/14/2017 06:32 AM, Dave Jones wrote: On 11/14/2017 02:37 AM, Merijn van den Kroonenberg wrote: seeing the cron output (also from mkupdates) it looks like /usr/local/spamassassin/automc/svn/trunk is now readonly? -Original Message- From: Cron Daemon Sent: Tuesday, November 14, 2017 9:30 AM To: sysadmins@spamassassin.apache.org Subject: Cron ~/svn/trunk/build/mkupdates/run_nightly | /usr/bin/tee /var/www/automc.spamassassin.org/mkupdates/mkupdates.txt + promote_active_rules + pwd + /usr/bin/perl build/mkupdates/listpromotable /usr/local/spamassassin/automc/svn/trunk /usr/local/spamassassin/automc/svn/trunk/build/mkupdates/run_nightly: line 20: rules/active.list.new: Permission denied + exit 1 I will fix this. I tried to reset the trunk yesterday on the server to make sure it was completely in sync with SVN and I guess I left off the "s" in the https: URL. http: is the read-only URL and https: is the read-write URL. I did an "svn info trunk" on it and copy/pasted the URL. There's probably a better way to force a reset on an SVN dir that I should have used. Dave I know what happened. I ran the co as root and I needed to be the automc user. Perms were wrong but fixed now. Dave
Cron <automc@sa-vm1> ~/svn/trunk/build/mkupdates/run_nightly | /usr/bin/tee /var/www/automc.spamassassin.org/mkupdates/mkupdates.txt
+ promote_active_rules + pwd + /usr/bin/perl build/mkupdates/listpromotable /usr/local/spamassassin/automc/svn/trunk /usr/local/spamassassin/automc/svn/trunk/build/mkupdates/run_nightly: line 20: rules/active.list.new: Permission denied + exit 1
Cron <automc@sa-vm1> svn update ~/svn/trunk/build/mkupdates > /dev/null
svn: E155004: Run 'svn cleanup' to remove locks (type 'svn help cleanup' for details) svn: E155004: Failed to lock working copy '/usr/local/spamassassin/automc/svn/trunk/build'. svn: E200031: sqlite[S8]: attempt to write a readonly database svn: E200042: Additional errors: svn: E200031: sqlite[S8]: attempt to write a readonly database
