Re: Encryption and Backups was Re: Onboarding, Documentation, etc.
On 5/13/2017 10:25 AM, Dave Jones wrote: How exactly do you want them to be stored? I am not familiar with doing this. The process I have seen used in the ASF is to use gpg to encrypt the files hence why one of the requests for you and Bryan was for your public keys to be put up on people. I was under the impression when you told me "there were things all over the place that updated DNS" this could be from other servers too. I may have over stated the issue, sorry. As we bring things back online, we'll find out :-) My concern is that in the past, we used so much of a VM machine's resources that it brought the machine to it's knees. So sa-vm1 being ramped up could bring that same issue to light. So if you see the legacy list of machines, there was a lot more systems involved. If we can get down to just one box, it'll be simple. But if we need more boxes, sobeit! This would be good to use something like a LastPass shared note. I use LastPass extensively for personal and work (LastPass Enterprise). Agreed. LastPass, OnePass, etc. As Bryan comes onboard, I'll look at what needs to be encrypted and if it gets too much, we can look at that. Regards, KAM -- Kevin A. McGrail Asst. Treasurer, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project
Re: Onboarding, Documentation, etc.
On 5/13/2017 9:50 AM, Dave Jones wrote: I am not sure about my goal since it may be in slight conflict with your goal. :) I would like SA to be a little more toward a complete spam filter out of the box so people don't have to spend years learning all of the ins and outs to make it effective. I understand that SA can't be complete out of the box for every mail environment is a little different but I feel that it could be improved a little more with some default rules. I support you adding it. So it's helpful for you to know where I'm coming from AND that I support differing goals. We are volunteers so there is no necessity for a hugely unified vision. And note that I have supported and kept masscheck/ruleqa going as best I could for two decades with significant resources starting even prior to project under SA. Even though I do not use the results of either system in production. Will do. I thought about leaving it out since we aren't using that DNS server anymore. Brian's longtime support of this project and his visibility in the OSS community are more valuable than you might know. I hope we can figure out something to get him back in the mix and keep him interested in helping! This is a link in the "Hidden Slave" on the DNS Hosting table. I you want it more prominent, then I can change the link to show the URL. I'm sure it is fine and I just missed it. Is the "incoming" server still around? I wasn't able to resolve it in DNS yesterday or today. Yes, it's named incoming.spamassassin.org. I might have used a.o by accident. BTW, can you add a.o and s.a.o to the acronyms list? This is documented under the SVN section. The RO and RW should be self explanatory to a sysadmin. Fair enough. Some hurdles are good to have :-) It's not under the Workflow section but parallel with the Onboarding so new people would see it. After you read the acronymns once, you should have them down. It's a source of reference for all admins that lives and breaths. Leaving it under Onboarding implies they never need to read it again which might prove false. Do you want to document stuff twice and have to maintain it in two places? The steps, yes. perhaps not the exact details So perhaps - Email sysadmins-subscr...@spamassassin.apache.org changes to - Subscribe to sysadmins@spamassassin.apache.org and the instructions remain in the section below. However, as evidenced by Bryan still working to onboard, simplification is needed. I want to specifically hold the hand of new sysadmins at least to the point where they can leave the nest to fly or flop. Regards, KAM
Re: Onboarding, Documentation, etc.
On 05/13/2017 08:13 AM, Kevin A. McGrail wrote: On 5/12/2017 7:32 PM, Dave Jones wrote: I have all of this information on https://wiki.apache.org/spamassassin/InfraNotes2017 now. Please review and comment/update as needed. Overall, the organization and edits are very good. Thanks for fixing Tenets, I knew that word looked wrong! I added a goal section with my goal. I suggest you add your goal as well and I've put this on the onboarding task list. I am not sure about my goal since it may be in slight conflict with your goal. :) I would like SA to be a little more toward a complete spam filter out of the box so people don't have to spend years learning all of the ins and outs to make it effective. I understand that SA can't be complete out of the box for every mail environment is a little different but I feel that it could be improved a little more with some default rules. Rather than edit directly, I wanted to ask that you do it to look at what I wrote and to explain why it's needed. NOTE: Some of these are edited from the previous send as I look them over again. *- Credentials:* - There are legacy shared credentials for elevated access on older machines. These must be encrypted and stored in SVN. The project is slowly moving away from these concepts. Got it. *- Under DNS, *List Hyperreal and that it is currently offline because we can't get DJBDNS to transfer a record. Contact for HyperReal is Brian Behlendorf Will do. I thought about leaving it out since we aren't using that DNS server anymore. - I would also add this information for Sonic in case their IPs change, etc. https://wiki.sonic.net/wiki/Secondary_DNS_Service is the current configuration information you will need. This is a link in the "Hidden Slave" on the DNS Hosting table. I you want it more prominent, then I can change the link to show the URL. I don't see this section and it will be important in the detective work as you read scripts. Even I have to refer to it quite often when I come across legacy documentation to figure out where something points to now. *- Project Machines* This is a short description of the machines involved including those that USED to exist and why. OLD: - Hyperion.Apache.org - ftp://ftp.ist.utl.pt/apache/dev/machines.html#hyperion shows this was likely a solaris box that I had access to when zones died and I had to recover data. - SpamAssassin.zones.apache.org - DIED - was replaced with spamassassin-vm - SpamAssassin.zones2.apache.org - deprecated by Infra - spamassassin-vm.apache.org - deprecated by Infra CURRENT: - incoming.apache.org - Donated by Sonic Is the "incoming" server still around? I wasn't able to resolve it in DNS yesterday or today. - sa-vm1.apache.org - Ubuntu box to replace spamassassin-vm and zones2 - Other Aliases: buildbot, ruleqa (there might be more). Also, this is an ASF box for all committers: - Minotaur.apache.org aka People - This used to handle various build and devel related tasks. Minotaur.apache.org for ssh (It appears that minotaur is not the proper server anymore. I used home.apache.org per some links that Sidney sent. (Home.apache.org and people.apache.org resolve to the same IP.) *Under the standards,* I would add this as someone will ask if we can use XYZ - Ubuntu? Ubuntu is the ASF Infrastructures OS of choice. Supporting others is not an option at this time. *I think this section is important *especially because it needs others added to it. - How to get access to each machine: sa-vm1.apache.org (current as of 4/28/17) - Open a Jira ticket with the availid of the person(s) you want to have access. Note if they need sudo access or not. - User self maintains their ssh-key at id.apache.org - NOTE: if sudo access was requested, run and sets up 'ortpasswd' Got it. *I would add this:* Will do. - Why all the boxes? The resources for Masscheck can be very intensive on CPU, Ram and disk I/O intensive. Over the years, many boxes have been consolidated, donated, lost, replaced, moved under ASF Infrastructure or just fell over and sank into the swamp. - Some boxes are just names for other boxes trap-proc.spamassassin.org. Sonic has scripts set up to archive collected spam to that server. *I would add this:* Will do. SVN: - You need access to https://svn.apache.org/repos/asf/spamassassin/ for sysadmin, dns and site. - In the ASF, we use http for read-only access to a repo and https for read-write. So if you are trying to checkout and modify a repo, make sure you are using https:// This is documented under the SVN section. The RO and RW should be self explanatory to a sysadmin. Encrypted SVN: - If you can, document things in the Wiki at https://wiki.apache.org/spamassassin/DevelopmentStuff. If something is sensitive, encrypt it and store it on the https://svn.apache.org/repos/asf/spamassassin/sysadmins repo and reference it on the Wiki.
Encryption and Backups was Re: Onboarding, Documentation, etc.
On 5/12/2017 7:32 PM, Dave Jones wrote: One thing we need to specify in more detail is the way we are going to encrypt things in the sysadmins repo. We don't want to put the encryption details on the wiki per se since it's public. The only thing I envision in the repo encrypted is passwords. For example, the PowerDNS API key is in the pdns.local.conf file. I believe documenting the location of the API key in the Wiki is sufficient. The local firewall allows port 8081 inbound from any source and the conf file is restricting which IPs the daemon will respond to. I would like to restrict the PowerDNS web server/API to specific source IPs matching the conf file for dual layers of protection. Good idea! We still shouldn't document publicly the PowerDNS API key but where should we document that? It will be in many scripts on servers that need to update DNS records so that will be a form of documentation if we reference the scripts on the wiki. I don't think there are many servers that update the DNS records. If there are, we can talk more but I believe it's just a local script on that one box when we get it working. In my opinion, referencing scripts and config files on the wiki is good enough for documenting sensitive information. Agreed but there are some items like root level passwords to old boxes, a shared signing key, etc. that can be at least temporarily stored in svn encrypted. For example, there is a box called incoming. I have the root password. But I'd prefer to not use it and switch to sudo and add accounts for you two. Regards, KAM
Re: Onboarding, Documentation, etc.
On 5/13/2017 9:13 AM, Kevin A. McGrail wrote: On 5/12/2017 7:32 PM, Dave Jones wrote: I have all of this information on https://wiki.apache.org/spamassassin/InfraNotes2017 now. Please review and comment/update as needed. Overall, the organization and edits are very good. Thanks for fixing Tenets, I knew that word looked wrong! I also think this information should be more clearly documented as I forgot it :-) Write access to the wiki is to anyone who has created a login name on the wiki whose name has been added to the page https://wiki.apache.org/spamassassin/ContributorsGroup Write access to that page is to anyone whose wiki login name has been added to https://wiki.apache.org/spamassassin/AdminGroup -- Kevin A. McGrail Asst. Treasurer, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project
Re: Onboarding, Documentation, etc.
On 5/12/2017 7:32 PM, Dave Jones wrote: I have all of this information on https://wiki.apache.org/spamassassin/InfraNotes2017 now. Please review and comment/update as needed. Overall, the organization and edits are very good. Thanks for fixing Tenets, I knew that word looked wrong! I added a goal section with my goal. I suggest you add your goal as well and I've put this on the onboarding task list. Rather than edit directly, I wanted to ask that you do it to look at what I wrote and to explain why it's needed. NOTE: Some of these are edited from the previous send as I look them over again. *- Credentials:* - There are legacy shared credentials for elevated access on older machines. These must be encrypted and stored in SVN. The project is slowly moving away from these concepts. *- Under DNS, *List Hyperreal and that it is currently offline because we can't get DJBDNS to transfer a record. Contact for HyperReal is Brian Behlendorf - I would also add this information for Sonic in case their IPs change, etc. https://wiki.sonic.net/wiki/Secondary_DNS_Service is the current configuration information you will need. I don't see this section and it will be important in the detective work as you read scripts. Even I have to refer to it quite often when I come across legacy documentation to figure out where something points to now. *- Project Machines* This is a short description of the machines involved including those that USED to exist and why. OLD: - Hyperion.Apache.org - ftp://ftp.ist.utl.pt/apache/dev/machines.html#hyperion shows this was likely a solaris box that I had access to when zones died and I had to recover data. - SpamAssassin.zones.apache.org - DIED - was replaced with spamassassin-vm - SpamAssassin.zones2.apache.org - deprecated by Infra - spamassassin-vm.apache.org - deprecated by Infra CURRENT: - incoming.apache.org - Donated by Sonic - sa-vm1.apache.org - Ubuntu box to replace spamassassin-vm and zones2 - Other Aliases: buildbot, ruleqa (there might be more). Also, this is an ASF box for all committers: - Minotaur.apache.org aka People - This used to handle various build and devel related tasks. Minotaur.apache.org for ssh (It appears that minotaur is not the proper server anymore. I used home.apache.org per some links that Sidney sent. (Home.apache.org and people.apache.org resolve to the same IP.) *Under the standards,* I would add this as someone will ask if we can use XYZ - Ubuntu? Ubuntu is the ASF Infrastructures OS of choice. Supporting others is not an option at this time. *I think this section is important *especially because it needs others added to it. - How to get access to each machine: sa-vm1.apache.org (current as of 4/28/17) - Open a Jira ticket with the availid of the person(s) you want to have access. Note if they need sudo access or not. - User self maintains their ssh-key at id.apache.org - NOTE: if sudo access was requested, run and sets up 'ortpasswd' *I would add this:* - Why all the boxes? The resources for Masscheck can be very intensive on CPU, Ram and disk I/O intensive. Over the years, many boxes have been consolidated, donated, lost, replaced, moved under ASF Infrastructure or just fell over and sank into the swamp. - Some boxes are just names for other boxes trap-proc.spamassassin.org. Sonic has scripts set up to archive collected spam to that server. *I would add this:* SVN: - You need access to https://svn.apache.org/repos/asf/spamassassin/ for sysadmin, dns and site. - In the ASF, we use http for read-only access to a repo and https for read-write. So if you are trying to checkout and modify a repo, make sure you are using https:// Encrypted SVN: - If you can, document things in the Wiki at https://wiki.apache.org/spamassassin/DevelopmentStuff. If something is sensitive, encrypt it and store it on the https://svn.apache.org/repos/asf/spamassassin/sysadmins repo and reference it on the Wiki. *The onboarding workflow *shouldn't include the important resources or acronyms IMO. Those are good for everyone which ties into... *The onboarding workflow *should have the extra steps added back not just the pointer to important resources. I am making it self-fulfilled and self-driven and trying to have a specific set of steps done so they can get to work as quickly as possible. - Once they have an Apache ID, they should: - SASA Member signs up for an Infra Jira account at https://issues.apache.org/jira/secure/Signup!default.jspa? - SASA Member adds an SSH public key to id.apache.org - Add your PGP public key. http://people.apache.org/~kmcgrail/ - Create an account on our Wiki - Email sysadmins-subscr...@spamassassin.apache.org - Email sysadmins@spamassassin.apache.org and ask for karma to access sa-vm1 with sudo access - Email sysadmins@spamassassin.apache.org and ask for your account to be added to
Re: Onboarding, Documentation, etc.
I have all of this information on https://wiki.apache.org/spamassassin/InfraNotes2017 now. Please review and comment/update as needed. One thing we need to specify in more detail is the way we are going to encrypt things in the sysadmins repo. We don't want to put the encryption details on the wiki per se since it's public. For example, the PowerDNS API key is in the pdns.local.conf file. The local firewall allows port 8081 inbound from any source and the conf file is restricting which IPs the daemon will respond to. I would like to restrict the PowerDNS web server/API to specific source IPs matching the conf file for dual layers of protection. We still shouldn't document publicly the PowerDNS API key but where should we document that? It will be in many scripts on servers that need to update DNS records so that will be a form of documentation if we reference the scripts on the wiki. In my opinion, referencing scripts and config files on the wiki is good enough for documenting sensitive information. Dave On 05/08/2017 05:13 PM, Kevin A. McGrail wrote: Dave and Bryan, below is my latest attempt at the how to information for sysadmins. Can one of you please take on incorporating this into the wiki? Apache SpamAssassin SysAdmin How-To NOTE: This was written in April of 2017 to help modernize our system records - Other records: See https://wiki.apache.org/spamassassin/DevelopmentStuff - This document will likely be used to replace that page. - Wiki Access: Write access to the wiki is to anyone who has created a login name on the wiki whose name has been added to the page https://wiki.apache.org/spamassassin/ContributorsGroup Write access to that page is to anyone whose wiki login name has been added to https://wiki.apache.org/spamassassin/AdminGroup - Members of SA SysAdmins (SASA): Dave Jones - da...@apache.org Kevin A. McGrail - 703-798-0171 - kmcgr...@apache.org Bryan Vest - bv...@apache.org - Who's in Charge? The PMC. There is no leadership hierarchy in the SpamAssassin SysAdmins. NOTE: As with any ASF role, if you follow The Apache Way, you should feel empowered to Just Do It (TM Nike) For a SysAdmin, your solution works (Merit), it's well documented (Open) and supports the project (Community), you're good to go though as a SysAdmin you need to realize we have control over private data. All SASA members have been asked to follow the LISA Code of Ethics. Tenants we Follow: - The Apache Way, Shane Curcuru's post on this are a good point: http://theapacheway.com/ - LISA/Sage Code of Ethics, https://www.pccc.com/base.cgim?template=sage_code_of_ethics Important Resources: The ASF Infrastructure (Infra) Jira: https://issues.apache.org/jira/secure/Dashboard.jspa - Sign up at Jira isn't single sign on enabled. SpamAssassin Bugzilla: https://bz.apache.org/SpamAssassin/ Short-hand Notes: There are a lot of acronyms, even those that might be basic that will be defined here if we find there is confusion to make it easier to bring new sysadmin's onboard to make many hands make light work. Apache Software Foundation (ASF) Bugzilla (BZ) Apache SpamAssassin (SA) PMC (Project Management Committee) SVN (SubVersioN) Mailing Lists: - There is a dedicated SASA Mailing list sysadmins@spamassassin.apache.org. Additionally, our machines largely support the Rule QA process so rul...@spamassassin.apache.org should be subscribed to. Credentials: - There are legacy shared credentials. These must be encrypted and stored in SVN. OPIE: - To sudo to root, you need to use OPIE - See https://reference.apache.org/committer/opie DNS for SpamAssassin.org: - The server creates DNS entries on the fly so we do not use the ASF infrastructure for DNS. We have a hidden master that pushes to Hyperreal and Sonic Contact for HyperReal is Brian Behlendorf Contact for Sonic is grant.kel...@sonic.com The information located here: https://wiki.sonic.net/wiki/Secondary_DNS_Service is the current configuration information you will need. - Project Machines This is a short description of the machines involved including those that USED to exist and why. OLD: - Hyperion.Apache.org - ftp://ftp.ist.utl.pt/apache/dev/machines.html#hyperion shows this was likely a solaris box that I had access to when zones died and I had to recover data. - SpamAssassin.zones.apache.org - DIED - was replaced with spamassassin-vm - SpamAssassin.zones2.apache.org - deprecated by Infra - spamassassin-vm.apache.org - deprecated by Infra CURRENT: - incoming.apache.org - Donated by Sonic - sa-vm1.apache.org - Ubuntu box to replace spamassassin-vm and zones2 - Other Aliases: buildbot, ruleqa (there might be more). Also, this is an ASF box for all committers: - Minotaur.apache.org aka People - This used to handle various build and devel related tasks. Minotaur.apache.org for ssh (It appears that minotaur is not the proper server
