From george at ceetonetechnology.com Tue Sep 1 16:21:19 2015 From: george at ceetonetechnology.com (George Rosamond) Date: Tue, 1 Sep 2015 16:21:19 -0400 Subject: [talk] PCI scan and SSHD false positive Message-ID: <55E608BF.4020008@ceetonetechnology.com> I have a box that failed a PCI scan solely based on the recent SSHD vulnerabilities CVS-2014-2653. Needless to say, the box, running FreeBSD 10.2-stable r287217 is not vulnerable, as 10.2 vulnerabilities only affected up to r285978, plus PAM is disabled, no DNSSEC, no passwd auth, etc. However, since the SSHD version is OpenSSH_6.6.1p1, and 6.6 is affected, scanners determine it's vulnerable. I saw a Reddit thread about this in relation to pfSense, and the results are the same. It's a patched version of SSHD, and the stupid scanners only determine pass/fail based on version. I am having a hard time conveying this to the PCI scanner through the client. I assume every box not running SSH 6.7 is deemed vulnerable, since that's all these people are looking for. How have people dealt with this? g From briancoca+nycbug at gmail.com Tue Sep 1 18:13:09 2015 From: briancoca+nycbug at gmail.com (Brian Coca) Date: Tue, 1 Sep 2015 18:13:09 -0400 Subject: [talk] PCI scan and SSHD false positive In-Reply-To: <55E608BF.4020008@ceetonetechnology.com> References: <55E608BF.4020008@ceetonetechnology.com> Message-ID: George, Normally you get to do a remediation report on the audits, I have used these to point out 'This is a false positive' and linked to proper docs and actual exploit tests then in the next 'round', the scanner is supposed to be updated to avoid the false positive. This is my experience mostly tied to financial/big corp, smaller 'security' shops might not have their feedback formalized. Also I've dealt mostly with very bad auditors w/o much tech knowledge, just check boxes to fill, that said .... My advice is to look at CVE, point out any discrepancies (no mention of BSD?) and ask to see successful exploit test, not only version checking. Also links to 'official' BSD advisories pointing out the versions (or lack thereof) affected by the vulnerability. The more docs you push to them that look 'official' the less they'll push back. Sadly most audits I've seen are are blind 'runapp (nessus, metasploit, etc) => pdf with logo => $$$$ => repeat' with little to no thought involved other than making sure it is billable. But, good or bad, auditors normally respond to documentation, as much as possible and as 'official' as possible (mailing list == bad, website with advisory and a logo == good). good luck, ------------ Brian Coca From briancoca+nycbug at gmail.com Tue Sep 1 18:24:48 2015 From: briancoca+nycbug at gmail.com (Brian Coca) Date: Tue, 1 Sep 2015 18:24:48 -0400 Subject: [talk] classifying BSD init In-Reply-To: <55E48D9E.6030105@nomadlogic.org> References: <55E48D9E.6030105@nomadlogic.org> Message-ID: First of all, thanks for all the feedback, It seems clear that codewise I need to keep the current distinction that makes the systems specific to each BSD. But part of my consideration of making this a single vs multiple plugins is that one of the project goals is to simplify administration. The current service module give a very generic and simple interface: # make sure sshd is started and will start at boot - service: name=sshd state=started enabled=yes In the case of systemd and upstart we have plenty of 'special' requirements or very specific calls that need to be added, like systemd's daemon-reload, reenable, etc. Which is my main reason to split the service plugin. But in the case of sysvinit and the BSD inits most of the functionality seems to still be uniform (even if the implementations are not). Can I get away with keeping sysvinit, openrc and the BSD inits in one module? the code would still be a bit complex and handle the different implementations, but I expect that they all have the same simple interface. Or am I missing some functionality that would change the interface for the BSDs? It would be nice that the most work to port a configuration from one system to the other would be replacing the service name. Thanks in advance, PS. I'm already adding DragonFly and Bitrig to proper detection and equating them mostly to FreeBSD and OpenBSD respectively. ----------- Brian Coca From george at ceetonetechnology.com Wed Sep 2 10:56:24 2015 From: george at ceetonetechnology.com (George Rosamond) Date: Wed, 2 Sep 2015 10:56:24 -0400 Subject: [talk] PCI scan and SSHD false positive In-Reply-To: References: <55E608BF.4020008@ceetonetechnology.com> Message-ID: <55E70E18.1060201@ceetonetechnology.com> Brian Coca: > George, > > Normally you get to do a remediation report on the audits, I have > used these to point out 'This is a false positive' and linked to > proper docs and actual exploit tests then in the next 'round', the > scanner is supposed to be updated to avoid the false positive. Yes, that is what I did, and it was rejected. > > This is my experience mostly tied to financial/big corp, smaller > 'security' shops might not have their feedback formalized. Also I've > dealt mostly with very bad auditors w/o much tech knowledge, just > check boxes to fill, that said .... It's a good point to note the type of firm doing the audit. You would assume lots of hosts are running OpenSSH patched versions, not just FreeBSD, and they clearly haven't experienced that. > > My advice is to look at CVE, point out any discrepancies (no mention > of BSD?) and ask to see successful exploit test, not only version > checking. Also links to 'official' BSD advisories pointing out the > versions (or lack thereof) affected by the vulnerability. The more > docs you push to them that look 'official' the less they'll push back. > Ha.. yeah! An exploit test or a version check? I think it would be asking way too much to actually get an exploit test. If they did, it would have been a closed case even before the box was updated to the OpenSSH patched version. The FreeBSD sec advisory was sent to them... and I noted in detail why we weren't affected. > Sadly most audits I've seen are are blind 'runapp (nessus, metasploit, > etc) => pdf with logo => $$$$ => repeat' with little to no thought > involved other than making sure it is billable. > But, good or bad, auditors normally respond to documentation, as much > as possible and as 'official' as possible (mailing list == bad, > website with advisory and a logo == good). Thanks for the feedback Brian, and also the offlist people. I think Nessus is beyond these auditors though. I can't imagine this is anything more than version checks, SSLLab.com results, etc. g From patrik at sigterm.se Wed Sep 2 15:23:40 2015 From: patrik at sigterm.se (Patrik Lundin) Date: Wed, 2 Sep 2015 21:23:40 +0200 Subject: [talk] classifying BSD init In-Reply-To: References: Message-ID: <20150902192340.GA27352@major.strace.se> On Mon, Aug 31, 2015 at 07:48:23PM +0530, Sujit K M wrote: > > Just out of curiosity, what is the difference between one module per project and > the present scheme. IMHO there is a lot difference in *BSD as Project. Though > This might be true in the case Linux Distros. You have X11 Dbus it is > functioning > the same way in Linux Distros, But not in the case of BSD. > Currently there exists both modules that handle more than one system (like the service module), and modules that are separate based on what tool they manage (examples of these are the package management modules "apt", "yum" and "openbsd_pkg") which are separate modules but keep a similar list of base arguments that they understand. This means that while I can have a playbook that works on more than one operating system if it calls the service module, if I also want to install packages I would need to use the "pkg_mgr" fact instead of naming a specific module by name. Just the direction of standardizing on one scheme for handling OS agnostic playbooks seems like a good thing to me. Going in the opposite direction and trying to merge the package management modules would probably create quite a massive module (and lets not forget that while we generally have enough bandwidth to go around it might be wasteful to have ansible upload large amounts of code that is never run to all managed systems). Another reason why I like the idea of splitting the module is because it separates the logic of deciding "what tool to use" from the actual tool logic. This is not that big of a deal for the *BSD classes because they are already nicely compartmentalized, but the Linux class is pretty complex as it stands right now. -- Patrik Lundin From sjt.kar at gmail.com Thu Sep 3 00:15:03 2015 From: sjt.kar at gmail.com (Sujit K M) Date: Thu, 3 Sep 2015 09:45:03 +0530 Subject: [talk] classifying BSD init In-Reply-To: <20150902192340.GA27352@major.strace.se> References: <20150902192340.GA27352@major.strace.se> Message-ID: On Thu, Sep 3, 2015 at 12:53 AM, Patrik Lundin wrote: > On Mon, Aug 31, 2015 at 07:48:23PM +0530, Sujit K M wrote: >> >> Just out of curiosity, what is the difference between one module per project and >> the present scheme. IMHO there is a lot difference in *BSD as Project. Though >> This might be true in the case Linux Distros. You have X11 Dbus it is >> functioning >> the same way in Linux Distros, But not in the case of BSD. >> > > Currently there exists both modules that handle more than one system > (like the service module), and modules that are separate based on what > tool they manage (examples of these are the package management modules > "apt", "yum" and "openbsd_pkg") which are separate modules but keep a > similar list of base arguments that they understand. Are you sure regarding this? All I see in the current implementation is similar arguments only on the derivative. Like Linux Distros. BSD only. > > This means that while I can have a playbook that works on more than one > operating system if it calls the service module, if I also want to > install packages I would need to use the "pkg_mgr" fact instead of > naming a specific module by name. > > Just the direction of standardizing on one scheme for handling OS agnostic > playbooks seems like a good thing to me. Going in the opposite direction > and trying to merge the package management modules would probably create > quite a massive module (and lets not forget that while we generally have > enough bandwidth to go around it might be wasteful to have ansible > upload large amounts of code that is never run to all managed systems). > > Another reason why I like the idea of splitting the module is because > it separates the logic of deciding "what tool to use" from the actual > tool logic. This is not that big of a deal for the *BSD classes because > they are already nicely compartmentalized, but the Linux class is pretty > complex as it stands right now. In Ansible It get the OS dependent information every time it upgrades or installs a package. From patrik at sigterm.se Sat Sep 5 09:17:22 2015 From: patrik at sigterm.se (Patrik Lundin) Date: Sat, 5 Sep 2015 15:17:22 +0200 Subject: [talk] classifying BSD init In-Reply-To: References: <20150902192340.GA27352@major.strace.se> Message-ID: <20150905131722.GA32709@major.strace.se> On Thu, Sep 03, 2015 at 09:45:03AM +0530, Sujit K M wrote: > On Thu, Sep 3, 2015 at 12:53 AM, Patrik Lundin wrote: > > > > Currently there exists both modules that handle more than one system > > (like the service module), and modules that are separate based on what > > tool they manage (examples of these are the package management modules > > "apt", "yum" and "openbsd_pkg") which are separate modules but keep a > > similar list of base arguments that they understand. > > Are you sure regarding this? All I see in the current implementation is similar > arguments only on the derivative. Like Linux Distros. BSD only. > I am not sure what you are asking if I am sure about. I am referring to the ansible modules, not the backend tools. Compare the following: http://docs.ansible.com/ansible/yum_module.html http://docs.ansible.com/ansible/apt_module.html http://docs.ansible.com/ansible/openbsd_pkg_module.html They all understand the "name" and "state" arguments. This is what I mean when I say they take similar basic arguments. > > > > This means that while I can have a playbook that works on more than one > > operating system if it calls the service module, if I also want to > > install packages I would need to use the "pkg_mgr" fact instead of > > naming a specific module by name. > > > > Just the direction of standardizing on one scheme for handling OS agnostic > > playbooks seems like a good thing to me. Going in the opposite direction > > and trying to merge the package management modules would probably create > > quite a massive module (and lets not forget that while we generally have > > enough bandwidth to go around it might be wasteful to have ansible > > upload large amounts of code that is never run to all managed systems). > > > > Another reason why I like the idea of splitting the module is because > > it separates the logic of deciding "what tool to use" from the actual > > tool logic. This is not that big of a deal for the *BSD classes because > > they are already nicely compartmentalized, but the Linux class is pretty > > complex as it stands right now. > > In Ansible It get the OS dependent information every time it upgrades > or installs > a package. > I dont understand what you mean by this. -- Patrik Lundin From kmsujit at gmail.com Sat Sep 5 22:14:32 2015 From: kmsujit at gmail.com (Sujit K M) Date: Sun, 6 Sep 2015 07:44:32 +0530 Subject: [talk] classifying BSD init In-Reply-To: <20150905131722.GA32709@major.strace.se> References: <20150902192340.GA27352@major.strace.se> <20150905131722.GA32709@major.strace.se> Message-ID: On Sat, Sep 5, 2015 at 6:47 PM, Patrik Lundin wrote: > On Thu, Sep 03, 2015 at 09:45:03AM +0530, Sujit K M wrote: >> On Thu, Sep 3, 2015 at 12:53 AM, Patrik Lundin wrote: >> > >> > Currently there exists both modules that handle more than one system >> > (like the service module), and modules that are separate based on what >> > tool they manage (examples of these are the package management modules >> > "apt", "yum" and "openbsd_pkg") which are separate modules but keep a >> > similar list of base arguments that they understand. >> >> Are you sure regarding this? All I see in the current implementation is similar >> arguments only on the derivative. Like Linux Distros. BSD only. >> > > I am not sure what you are asking if I am sure about. I am > referring to the ansible modules, not the backend tools. Compare the > following: > > http://docs.ansible.com/ansible/yum_module.html > http://docs.ansible.com/ansible/apt_module.html > http://docs.ansible.com/ansible/openbsd_pkg_module.html > > They all understand the "name" and "state" arguments. This is what I > mean when I say they take similar basic arguments These are just documentation of the yum/apt or openbsd modules. Below what I mean. https://raymii.org/s/tutorials/Ansible_-_Only_if_on_specific_distribution_or_distribution_version.html >> > >> > This means that while I can have a playbook that works on more than one >> > operating system if it calls the service module, if I also want to >> > install packages I would need to use the "pkg_mgr" fact instead of >> > naming a specific module by name. >> > >> > Just the direction of standardizing on one scheme for handling OS agnostic >> > playbooks seems like a good thing to me. Going in the opposite direction >> > and trying to merge the package management modules would probably create >> > quite a massive module (and lets not forget that while we generally have >> > enough bandwidth to go around it might be wasteful to have ansible >> > upload large amounts of code that is never run to all managed systems). >> > >> > Another reason why I like the idea of splitting the module is because >> > it separates the logic of deciding "what tool to use" from the actual >> > tool logic. This is not that big of a deal for the *BSD classes because >> > they are already nicely compartmentalized, but the Linux class is pretty >> > complex as it stands right now. >> >> In Ansible It get the OS dependent information every time it upgrades >> or installs >> a package. >> > > I dont understand what you mean by this. Well what I mean is given below. http://docs.ansible.com/ansible/playbooks_variables.html#information-discovered-from-systems-facts From patrik at sigterm.se Sun Sep 6 05:38:26 2015 From: patrik at sigterm.se (Patrik Lundin) Date: Sun, 6 Sep 2015 11:38:26 +0200 Subject: [talk] classifying BSD init In-Reply-To: References: <20150902192340.GA27352@major.strace.se> <20150905131722.GA32709@major.strace.se> Message-ID: <20150906093826.GA2588@major.strace.se> On Sun, Sep 06, 2015 at 07:44:32AM +0530, Sujit K M wrote: > On Sat, Sep 5, 2015 at 6:47 PM, Patrik Lundin wrote: > > These are just documentation of the yum/apt or openbsd modules. Below > what I mean. > > https://raymii.org/s/tutorials/Ansible_-_Only_if_on_specific_distribution_or_distribution_version.html > What I am aiming for is writing playbooks where ansible already takes care of the "when: ansible_distribution ==" magic (which it does, and populates the "ansible_pkg_mgr" fact for you). > >> > >> In Ansible It get the OS dependent information every time it upgrades > >> or installs > >> a package. > >> > > > > I dont understand what you mean by this. > > Well what I mean is given below. > > http://docs.ansible.com/ansible/playbooks_variables.html#information-discovered-from-systems-facts > Note that the "ansible_pkg_mgr" fact exists in that listing, already taking care of the decision of what module to use so you dont need that extra scaffolding in the playbook. There is however no "service" equivalent fact since the same module is used on all platforms, which is kind of a discrepancy. Standardizing on one way of doing this is all I am saying is a good thing. Hope this explains what I mean :). -- Patrik Lundin From kmsujit at gmail.com Sun Sep 6 06:16:30 2015 From: kmsujit at gmail.com (Sujit K M) Date: Sun, 6 Sep 2015 15:46:30 +0530 Subject: [talk] New Ideas Ansible Unify or Not: was Re: classifying BSD init Message-ID: On Sun, Sep 6, 2015 at 3:08 PM, Patrik Lundin wrote: > On Sun, Sep 06, 2015 at 07:44:32AM +0530, Sujit K M wrote: >> On Sat, Sep 5, 2015 at 6:47 PM, Patrik Lundin wrote: >> >> These are just documentation of the yum/apt or openbsd modules. Below >> what I mean. >> >> https://raymii.org/s/tutorials/Ansible_-_Only_if_on_specific_distribution_or_distribution_version.html >> > > What I am aiming for is writing playbooks where ansible already takes > care of the "when: ansible_distribution ==" magic (which it does, and > populates the "ansible_pkg_mgr" fact for you). So why do you want to do this? I am still not clear on what you are trying to Unify. Say are writing a playbook for apache HTTPD, which I hope is free from any Linux distributions, this should work cleanly right now. Could you be please be more clearer. From patrik at sigterm.se Sun Sep 6 06:40:40 2015 From: patrik at sigterm.se (Patrik Lundin) Date: Sun, 6 Sep 2015 12:40:40 +0200 Subject: [talk] New Ideas Ansible Unify or Not: was Re: classifying BSD init In-Reply-To: References: Message-ID: <20150906104039.GA19218@major.strace.se> On Sun, Sep 06, 2015 at 03:46:30PM +0530, Sujit K M wrote: > On Sun, Sep 6, 2015 at 3:08 PM, Patrik Lundin wrote: > > On Sun, Sep 06, 2015 at 07:44:32AM +0530, Sujit K M wrote: > >> On Sat, Sep 5, 2015 at 6:47 PM, Patrik Lundin wrote: > >> > >> These are just documentation of the yum/apt or openbsd modules. Below > >> what I mean. > >> > >> https://raymii.org/s/tutorials/Ansible_-_Only_if_on_specific_distribution_or_distribution_version.html > >> > > > > What I am aiming for is writing playbooks where ansible already takes > > care of the "when: ansible_distribution ==" magic (which it does, and > > populates the "ansible_pkg_mgr" fact for you). > > So why do you want to do this? > It is less to type, and less logic to keep track of yourself. > > Say are writing a playbook for apache HTTPD, which I hope is free from any Linux > distributions, this should work cleanly right now. Could you be please > be more clearer. > It can be done currently by calling $ansible_pkg_mgr for installing the package, and the "service" module directly for starting it. Being able to document that you should use $ansible_service_mgr instead makes the playbook layout more uniform in my view (and leads the way for how other modules performing another task using different backend tools should be written). I feel that this discussion should be continued in the context of PRs against the ansible code base. Hope you are OK with that. -- Patrik Lundin From kmsujit at gmail.com Sun Sep 6 07:00:26 2015 From: kmsujit at gmail.com (Sujit K M) Date: Sun, 6 Sep 2015 16:30:26 +0530 Subject: [talk] New Ideas Ansible Unify or Not: was Re: classifying BSD init In-Reply-To: <20150906104039.GA19218@major.strace.se> References: <20150906104039.GA19218@major.strace.se> Message-ID: On Sun, Sep 6, 2015 at 4:10 PM, Patrik Lundin wrote: > On Sun, Sep 06, 2015 at 03:46:30PM +0530, Sujit K M wrote: >> On Sun, Sep 6, 2015 at 3:08 PM, Patrik Lundin wrote: >> > On Sun, Sep 06, 2015 at 07:44:32AM +0530, Sujit K M wrote: >> >> On Sat, Sep 5, 2015 at 6:47 PM, Patrik Lundin wrote: >> >> >> >> These are just documentation of the yum/apt or openbsd modules. Below >> >> what I mean. >> >> >> >> https://raymii.org/s/tutorials/Ansible_-_Only_if_on_specific_distribution_or_distribution_version.html >> >> >> > >> > What I am aiming for is writing playbooks where ansible already takes >> > care of the "when: ansible_distribution ==" magic (which it does, and >> > populates the "ansible_pkg_mgr" fact for you). >> >> So why do you want to do this? >> > > It is less to type, and less logic to keep track of yourself. This is ridicules, Why cannot you use Cntr - Shift - R >> >> Say are writing a playbook for apache HTTPD, which I hope is free from any Linux >> distributions, this should work cleanly right now. Could you be please >> be more clearer. >> > > It can be done currently by calling $ansible_pkg_mgr for installing the package, > and the "service" module directly for starting it. > > Being able to document that you should use $ansible_service_mgr instead > makes the playbook layout more uniform in my view (and leads the way for > how other modules performing another task using different backend tools > should be written). Could you please go less to code and more to your design or scenarios you are trying to cover. > I feel that this discussion should be continued in the context of PRs > against the ansible code base. Hope you are OK with that. What ever discussions we are having according to me are not even touching 1% of any purpose. You seem more interested in building your logic or code which is not required as per me, as you are taking more in code that needs to be covered. This certainly cannot go to code in my view. Also You don't seem to be interested in Linux Or Other Operating Systems, or How you are achieving this. This certainly cannot be only a BSD Thing. I am OK to Put in PR If you can present a statement of work and we/NYCBUG or Me approve it. And you can put it in your PR. From jhb at freebsd.org Tue Sep 8 14:26:58 2015 From: jhb at freebsd.org (John Baldwin) Date: Tue, 08 Sep 2015 11:26:58 -0700 Subject: [talk] virtualization support in openbsd In-Reply-To: <55E4A615.3010805@nomadlogic.org> References: <1441044735.984651.370858017.12B21498@webmail.messagingengine.com> <55E4A615.3010805@nomadlogic.org> Message-ID: <1625009.JRTEHLFOgD@ralph.baldwin.cx> On Monday, August 31, 2015 12:08:05 PM Pete Wright wrote: > > On 08/31/15 11:55, Justin Sherrill wrote: > > On Mon, Aug 31, 2015 at 2:44 PM, Malcolm Matalka wrote: > >> I don't know much about virtualization, how come not port kvm or bhyve? > >> > > > > Or Xen (which I think NetBSD is the only one supporting) or vkernels > > (DragonFly-only) or hey, jails, which has been around forever but > > everyone has a slightly different version of. > > > > freebsd also has continuing support being developed to Xen (as well as > support for virtual box). I believe dom0 works with PVH on amd64 in HEAD. I'm not sure how much of that is present in 10.x. I know that someone at Xen is working on arm support as well (possibly just aarch64) for dom0 and domU. I do think there are patches to add bhyve support to libvirt, though I have not followed to see if they are merged upstream. -- John Baldwin From george at ceetonetechnology.com Mon Sep 14 12:21:01 2015 From: george at ceetonetechnology.com (George Rosamond) Date: Mon, 14 Sep 2015 12:21:01 -0400 Subject: [talk] vBSDCon anyone? Message-ID: <55F6F3ED.4040508@ceetonetechnology.com> Did anyone attend vBSDCon? Curious to hear thoughts on it. g From bcallah at devio.us Mon Sep 14 12:24:07 2015 From: bcallah at devio.us (Brian Callahan) Date: Mon, 14 Sep 2015 12:24:07 -0400 Subject: [talk] vBSDCon anyone? In-Reply-To: <55F6F3ED.4040508@ceetonetechnology.com> References: <55F6F3ED.4040508@ceetonetechnology.com> Message-ID: <55F6F4A7.1040707@devio.us> On 9/14/2015 12:21 PM, George Rosamond wrote: > Did anyone attend vBSDCon? I certainly hope I was there this weekend, since I gave one of the talks :-) > Curious to hear thoughts on it. > Sure. I'll write up my thoughts tonight. ~Brian From george at ceetonetechnology.com Mon Sep 14 16:04:12 2015 From: george at ceetonetechnology.com (George Rosamond) Date: Mon, 14 Sep 2015 16:04:12 -0400 Subject: [talk] NYC*BUG: Upcoming and this Wednesday on OPNsense Message-ID: <55F7283C.8070205@ceetonetechnology.com> Were you at vBSDCon this past weekend? Hit talk@ with your impressions. ***** Sept 16, Wednesday, 1845 PM OPNsense: On the Shoulders of Giants, Isaac (.ike) Levy Stone Creek Bar & Lounge: 140 E 27th St Notice: this month will not be the usual first wed. Abstract OPNsense is a BSD-licensed, easy-to-use and easy-to-build FreeBSD-based firewall and routing platform. This presentation is a hands-on preview of OPNsense, and should appeal to a wide range of people looking for BSD based router and firewall platforms. With hands-on examples and gear on-site, we'll be covering: OPNsense Overview, a fast features walk-through As a fork of pfSense, why fork? Life with OPNsense today... Lots changing every week under the hood! Thanks to the stable FreeBSD Base, OPNsense is solid through changes. Goals through next spring... Implementation high-level, Technical aims of the project Why an appliance, why not a package? The roadmap/goals for 2016 Why a granular development process? HardenedBSD (Whaaaa?!) LibreSSL, OpenSSL Scratching my itch, Localized Translations! AWS/Cloud Images, (why? how?) OPNsense Project Future. ike's view of post-2016, many possibilities... Musing on building an appliance with FreeBSD Hands-on with hardware! Media [http://opnsense.org/] [http://dotike.github.io/opnsense.core.ja_JP.UTF8/] Speaker Bio Isaac (.ike) Levy is a crusty UNIX Hacker. ike, a long-time pfSense user, has moved on to become a contributor to the OPNSense project. Ike has been focused on i18n work, and Japanese translations, and for his sins, has been hacking on AWS AMI builds: http://dotike.github.io/opnsense.core.ja_JP.UTF8/ In 2006, ike gave an overview on pfSense and it`s mother project m0n0wall, which were new and exciting router platforms back then, "throw your Linksys/SoHo/WiFi router in the garbage where it belongs" In 2010, ike gave an overview of life with pfSense in Datacenter/Large deployments, "you might wanna` put your Sonicwall/Juniper/Cisco routers up on Ebay." A long-time community contributor to the *BSD's, ike is obsessed with high-availability and redundant networked servers systems, mostly because he likes to sleep at night. Standing on the shoulders of giants, his background includes partnering to run a Virtual Server ISP before anyone called it a cloud, as well as having a long history building internet-facing infrastructure with UNIX systems. .ike has been a part of NYC*BUG since it was first launched in January 2004. He was a long-time member of the Lower East Side Mac Unix User Group, and is still in denial that this group no longer exists. He has spoken frequently on a number of UNIX and internet security topics at various venues, particularly on the topic of FreeBSD's jail(8). From george at ceetonetechnology.com Tue Sep 15 23:58:29 2015 From: george at ceetonetechnology.com (George Rosamond) Date: Tue, 15 Sep 2015 23:58:29 -0400 Subject: [talk] NYC*BUG Wednesday: OPNsense Message-ID: <55F8E8E5.6060304@ceetonetechnology.com> September 16, Wednesday, 1845 OPNsense: On the Shoulders of Giants, Isaac (.ike) Levy Stone Creek Bar & Lounge: 140 E 27th St Notice: this month will not be the usual first wed. OPNsense is a BSD-licensed, easy-to-use and easy-to-build FreeBSD-based firewall and routing platform. This presentation is a hands-on preview of OPNsense, and should appeal to a wide range of people looking for BSD based router and firewall platforms. With hands-on examples and gear on-site, we'll be covering: OPNsense Overview, a fast features walk-through As a fork of pfSense, why fork? Life with OPNsense today... Lots changing every week under the hood! Thanks to the stable FreeBSD Base, OPNsense is solid through changes. Goals through next spring... Implementation high-level, Technical aims of the project Why an appliance, why not a package? The roadmap/goals for 2016 Why a granular development process? HardenedBSD (Whaaaa?!) LibreSSL, OpenSSL Scratching my itch, Localized Translations! AWS/Cloud Images, (why? how?) OPNsense Project Future. ike's view of post-2016, many possibilities... Musing on building an appliance with FreeBSD Hands-on with hardware! From george at ceetonetechnology.com Tue Sep 15 23:58:29 2015 From: george at ceetonetechnology.com (George Rosamond) Date: Tue, 15 Sep 2015 23:58:29 -0400 Subject: [talk] NYC*BUG Wednesday: OPNsense Message-ID: <55F8E8E5.2000600@ceetonetechnology.com> September 16, Wednesday, 1845 OPNsense: On the Shoulders of Giants, Isaac (.ike) Levy Stone Creek Bar & Lounge: 140 E 27th St Notice: this month will not be the usual first wed. OPNsense is a BSD-licensed, easy-to-use and easy-to-build FreeBSD-based firewall and routing platform. This presentation is a hands-on preview of OPNsense, and should appeal to a wide range of people looking for BSD based router and firewall platforms. With hands-on examples and gear on-site, we'll be covering: OPNsense Overview, a fast features walk-through As a fork of pfSense, why fork? Life with OPNsense today... Lots changing every week under the hood! Thanks to the stable FreeBSD Base, OPNsense is solid through changes. Goals through next spring... Implementation high-level, Technical aims of the project Why an appliance, why not a package? The roadmap/goals for 2016 Why a granular development process? HardenedBSD (Whaaaa?!) LibreSSL, OpenSSL Scratching my itch, Localized Translations! AWS/Cloud Images, (why? how?) OPNsense Project Future. ike's view of post-2016, many possibilities... Musing on building an appliance with FreeBSD Hands-on with hardware! From raulcuza at gmail.com Wed Sep 16 12:56:30 2015 From: raulcuza at gmail.com (Raul Cuza) Date: Wed, 16 Sep 2015 12:56:30 -0400 Subject: [talk] In Contrast to BSD init, A history of modern init systems (1992-2015) Message-ID: In light of the recent discussion on *BSD and init system, I thought this history of modern init systems a interesting contrast: http://blog.darknedgy.net/technology/2015/09/05/0/ By definition of "modern", the BSD style init is the "classical" that these systems are not. Maybe I don't understand the problems these alternatives are trying to solve sufficiently. If you can shed some light on it, I'd love to hear it. What I like most about the history is that most of those attempts at improvements have not impacted the systems I manage (conveniently ignoring the OS X fleets I've been in charge of at various times). For me, the classical solution gets the job done. Ra?l From george at ceetonetechnology.com Wed Sep 16 15:09:54 2015 From: george at ceetonetechnology.com (George Rosamond) Date: Wed, 16 Sep 2015 15:09:54 -0400 Subject: [talk] charger to meeting Message-ID: <55F9BE82.2060101@ceetonetechnology.com> If you have it around, could someone bring an Apple MagSafe charger to the meeting tonight. Patrick M needs it. Thanks g From mmatalka at gmail.com Wed Sep 16 15:24:06 2015 From: mmatalka at gmail.com (Malcolm Matalka) Date: Wed, 16 Sep 2015 19:24:06 +0000 Subject: [talk] In Contrast to BSD init, A history of modern init systems (1992-2015) In-Reply-To: (Raul Cuza's message of "Wed, 16 Sep 2015 12:56:30 -0400") References: Message-ID: <86y4g6rwvd.fsf@gmail.com> Raul Cuza writes: > In light of the recent discussion on *BSD and init system, I thought > this history of modern init systems a interesting contrast: > http://blog.darknedgy.net/technology/2015/09/05/0/ > > By definition of "modern", the BSD style init is the "classical" that > these systems are not. Maybe I don't understand the problems these > alternatives are trying to solve sufficiently. If you can shed some > light on it, I'd love to hear it. I have not had a problem that these new systems solve either. I actually prefer daemontools out of all of these (not an init system, I know, but close enough for this discussion, I think), because it's very simple. In the case of a server, I'm not sure why one would want something more than something like daemontools. I can see an argument for something more sophisticated for a desktop environment but I'm not sure what that would really look like. I'm pretty biased in my opinion here though, so YMMV. > > What I like most about the history is that most of those attempts at > improvements have not impacted the systems I manage (conveniently > ignoring the OS X fleets I've been in charge of at various times). For > me, the classical solution gets the job done. > > Ra?l > > _______________________________________________ > talk mailing list > talk at lists.nycbug.org > http://lists.nycbug.org/mailman/listinfo/talk From _ at thomaslevine.com Thu Sep 17 15:58:02 2015 From: _ at thomaslevine.com (Thomas Levine) Date: Thu, 17 Sep 2015 15:58:02 -0400 Subject: [talk] Classic code review Message-ID: <20150917195802.GA21287@_> Could someone point me to the classic code review meeting that was mentioned last night? Thanks From george at ceetonetechnology.com Thu Sep 17 16:07:11 2015 From: george at ceetonetechnology.com (George Rosamond) Date: Thu, 17 Sep 2015 16:07:11 -0400 Subject: [talk] Classic code review In-Reply-To: <20150917195802.GA21287@_> References: <20150917195802.GA21287@_> Message-ID: <55FB1D6F.5090403@ceetonetechnology.com> Thomas Levine: > Could someone point me to the classic code review meeting that was > mentioned last night? Thanks > Thanks for asking... an announce will also go out about it soon: http://www.meetup.com/Classical-Code-Reading-Group-of-New-York/events/225026690/ Know where you stand: the `pwd` program 28 September 2015 thoughtbot - 1384 Broadway, 20th fl Not sure about the time, but it's probably on the data mining, er, Meetup.com page. g From kmsujit at gmail.com Fri Sep 18 09:43:29 2015 From: kmsujit at gmail.com (Sujit K M) Date: Fri, 18 Sep 2015 19:13:29 +0530 Subject: [talk] In Contrast to BSD init, A history of modern init systems (1992-2015) In-Reply-To: References: Message-ID: On Wed, Sep 16, 2015 at 10:26 PM, Raul Cuza wrote: > In light of the recent discussion on *BSD and init system, I thought > this history of modern init systems a interesting contrast: > http://blog.darknedgy.net/technology/2015/09/05/0/ > > By definition of "modern", the BSD style init is the "classical" that > these systems are not. Maybe I don't understand the problems these > alternatives are trying to solve sufficiently. If you can shed some > light on it, I'd love to hear it. Why don't you, any specific reasons? > > What I like most about the history is that most of those attempts at > improvements have not impacted the systems I manage (conveniently > ignoring the OS X fleets I've been in charge of at various times). For > me, the classical solution gets the job done. https://www.reddit.com/r/linux/comments/2nhkx9/freebsds_jordan_hubbard_sees_need_for_a_modern/ > > Ra?l > > _______________________________________________ > talk mailing list > talk at lists.nycbug.org > http://lists.nycbug.org/mailman/listinfo/talk From kmsujit at gmail.com Sat Sep 19 00:01:22 2015 From: kmsujit at gmail.com (Sujit K M) Date: Sat, 19 Sep 2015 09:31:22 +0530 Subject: [talk] In Contrast to BSD init, A history of modern init systems (1992-2015) In-Reply-To: <86y4g6rwvd.fsf@gmail.com> References: <86y4g6rwvd.fsf@gmail.com> Message-ID: On Thu, Sep 17, 2015 at 12:54 AM, Malcolm Matalka wrote: > Raul Cuza writes: > >> In light of the recent discussion on *BSD and init system, I thought >> this history of modern init systems a interesting contrast: >> http://blog.darknedgy.net/technology/2015/09/05/0/ >> >> By definition of "modern", the BSD style init is the "classical" that >> these systems are not. Maybe I don't understand the problems these >> alternatives are trying to solve sufficiently. If you can shed some >> light on it, I'd love to hear it. > > I have not had a problem that these new systems solve either. I > actually prefer daemontools out of all of these (not an init system, I > know, but close enough for this discussion, I think), because it's very > simple. In the case of a server, I'm not sure why one would want > something more than something like daemontools. I can see an argument > for something more sophisticated for a desktop environment but I'm not > sure what that would really look like. I'm pretty biased in my opinion > here though, so YMMV. Please stop promoting proprietary solutions to the list. >> What I like most about the history is that most of those attempts at >> improvements have not impacted the systems I manage (conveniently >> ignoring the OS X fleets I've been in charge of at various times). For >> me, the classical solution gets the job done. >> >> Ra?l >> >> _______________________________________________ >> talk mailing list >> talk at lists.nycbug.org >> http://lists.nycbug.org/mailman/listinfo/talk > > _______________________________________________ > talk mailing list > talk at lists.nycbug.org > http://lists.nycbug.org/mailman/listinfo/talk From george at ceetonetechnology.com Sat Sep 19 00:12:58 2015 From: george at ceetonetechnology.com (George Rosamond) Date: Sat, 19 Sep 2015 00:12:58 -0400 Subject: [talk] In Contrast to BSD init, A history of modern init systems (1992-2015) In-Reply-To: References: <86y4g6rwvd.fsf@gmail.com> Message-ID: <55FCE0CA.50701@ceetonetechnology.com> Sujit K M: > On Thu, Sep 17, 2015 at 12:54 AM, Malcolm Matalka wrote: >> Raul Cuza writes: >> >>> In light of the recent discussion on *BSD and init system, I thought >>> this history of modern init systems a interesting contrast: >>> http://blog.darknedgy.net/technology/2015/09/05/0/ >>> >>> By definition of "modern", the BSD style init is the "classical" that >>> these systems are not. Maybe I don't understand the problems these >>> alternatives are trying to solve sufficiently. If you can shed some >>> light on it, I'd love to hear it. >> >> I have not had a problem that these new systems solve either. I >> actually prefer daemontools out of all of these (not an init system, I >> know, but close enough for this discussion, I think), because it's very >> simple. In the case of a server, I'm not sure why one would want >> something more than something like daemontools. I can see an argument >> for something more sophisticated for a desktop environment but I'm not >> sure what that would really look like. I'm pretty biased in my opinion >> here though, so YMMV. > > Please stop promoting proprietary solutions to the list. If you're referring to daemontools, 'proprietary' is not an exactly accurate description, and it does exist in both FreeBSD (and therefore DFly) and pkgsrc ports, regardless of a layer of people's feelings about the licensing. Personally, 'kooky' might be more useful as a description of the past djb licenses. On that note, please don't attempt to mediate this mailing list. There are way more moderator eyes watching this discussion than you could imagine. Even if someone had noted a strength of some other explicitly proprietary solution as useful for their tasks at-hand, without doing some marketing spiel, it would still be an acceptable post. We can't be blind to the strengths of proprietary solutions. Lots of open source solutions wouldn't exist without appreciating strengths of closed solutions. g From kmsujit at gmail.com Sat Sep 19 00:35:43 2015 From: kmsujit at gmail.com (Sujit K M) Date: Sat, 19 Sep 2015 10:05:43 +0530 Subject: [talk] In Contrast to BSD init, A history of modern init systems (1992-2015) In-Reply-To: <55FCE0CA.50701@ceetonetechnology.com> References: <86y4g6rwvd.fsf@gmail.com> <55FCE0CA.50701@ceetonetechnology.com> Message-ID: George, Some thing simple, as you are pointing out that there are other people who are moderators in the list. I find it very disgusting to the sort of tone that is being used in these mails. Below Quote, If you are moderating the list then why are such posts coming through, Although language skills might be poor but more so of a case of why the person is find it necessary to question people. "Maybe I don't understand the problems these ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ alternatives are trying to solve sufficiently. If you can shed some ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ light on it, I'd love to hear it." ^^^^^^^^^^^^^^^^^^^^^^^^ On Sat, Sep 19, 2015 at 9:42 AM, George Rosamond wrote: > Sujit K M: >> On Thu, Sep 17, 2015 at 12:54 AM, Malcolm Matalka wrote: >>> Raul Cuza writes: >>> >>>> In light of the recent discussion on *BSD and init system, I thought >>>> this history of modern init systems a interesting contrast: >>>> http://blog.darknedgy.net/technology/2015/09/05/0/ >>>> >>>> By definition of "modern", the BSD style init is the "classical" that >>>> these systems are not. Maybe I don't understand the problems these >>>> alternatives are trying to solve sufficiently. If you can shed some >>>> light on it, I'd love to hear it. >>> >>> I have not had a problem that these new systems solve either. I >>> actually prefer daemontools out of all of these (not an init system, I >>> know, but close enough for this discussion, I think), because it's very >>> simple. In the case of a server, I'm not sure why one would want >>> something more than something like daemontools. I can see an argument >>> for something more sophisticated for a desktop environment but I'm not >>> sure what that would really look like. I'm pretty biased in my opinion >>> here though, so YMMV. >> >> Please stop promoting proprietary solutions to the list. > > If you're referring to daemontools, 'proprietary' is not an exactly > accurate description, and it does exist in both FreeBSD (and therefore > DFly) and pkgsrc ports, regardless of a layer of people's feelings about > the licensing. Personally, 'kooky' might be more useful as a description > of the past djb licenses. What is a 'kooky' license. > > On that note, please don't attempt to mediate this mailing list. There > are way more moderator eyes watching this discussion than you could I found it objectionable. I donot find it necessary to depend on another moderator to get a view. On this specific reason given below. > imagine. Even if someone had noted a strength of some other explicitly > proprietary solution as useful for their tasks at-hand, without doing > some marketing spiel, it would still be an acceptable post. Don't find it necessary to let some ask others to look at the source of a paid service. That is what I found the Member way doing. Quote below ">>>(not an init system, I >>> know, but close enough for this discussion, I think)" ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > We can't be blind to the strengths of proprietary solutions. Lots of > open source solutions wouldn't exist without appreciating strengths of > closed solutions. You can build on the strength of proprietary solutions. Build on companies investing on Open source. But in a manner better suited for people to understand. I mean, lay man who cannot invest in solutions provided by these companies. Misrepresentation seems to be the way out for many of these guru's in several of the posts that are being poste From mmatalka at gmail.com Sat Sep 19 03:06:57 2015 From: mmatalka at gmail.com (Malcolm Matalka) Date: Sat, 19 Sep 2015 07:06:57 +0000 Subject: [talk] In Contrast to BSD init, A history of modern init systems (1992-2015) In-Reply-To: (Sujit K. M.'s message of "Sat, 19 Sep 2015 09:31:22 +0530") References: <86y4g6rwvd.fsf@gmail.com> Message-ID: <864miqsx9q.fsf@gmail.com> Sujit K M writes: > > Please stop promoting proprietary solutions to the list. > daemontools is open source and has been modified/extended in multiple ways (daemontools-encore, runit). I'm not sure how I am promoting a proprietary solution, please enlighten me? From kmsujit at gmail.com Sat Sep 19 03:31:02 2015 From: kmsujit at gmail.com (Sujit K M) Date: Sat, 19 Sep 2015 13:01:02 +0530 Subject: [talk] In Contrast to BSD init, A history of modern init systems (1992-2015) In-Reply-To: <864miqsx9q.fsf@gmail.com> References: <86y4g6rwvd.fsf@gmail.com> <864miqsx9q.fsf@gmail.com> Message-ID: http://www.daemon-tools.cc/support/faq#free_or_not On Sat, Sep 19, 2015 at 12:36 PM, Malcolm Matalka wrote: > Sujit K M writes: > > >> >> Please stop promoting proprietary solutions to the list. >> > > daemontools is open source and has been modified/extended in multiple > ways (daemontools-encore, runit). I'm not sure how I am promoting a > proprietary solution, please enlighten me? From mmatalka at gmail.com Sat Sep 19 03:38:45 2015 From: mmatalka at gmail.com (Malcolm Matalka) Date: Sat, 19 Sep 2015 09:38:45 +0200 Subject: [talk] In Contrast to BSD init, A history of modern init systems (1992-2015) In-Reply-To: References: <86y4g6rwvd.fsf@gmail.com> <864miqsx9q.fsf@gmail.com> Message-ID: If you take a few minutes to read the website you'll notice that is imaging software, not an init system. The website you want is: http://cr.yp.to/daemontools.html Den 19 sep 2015 09:31 skrev "Sujit K M" : > http://www.daemon-tools.cc/support/faq#free_or_not > > On Sat, Sep 19, 2015 at 12:36 PM, Malcolm Matalka > wrote: > > Sujit K M writes: > > > > > >> > >> Please stop promoting proprietary solutions to the list. > >> > > > > daemontools is open source and has been modified/extended in multiple > > ways (daemontools-encore, runit). I'm not sure how I am promoting a > > proprietary solution, please enlighten me? > > _______________________________________________ > talk mailing list > talk at lists.nycbug.org > http://lists.nycbug.org/mailman/listinfo/talk > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kmsujit at gmail.com Sat Sep 19 03:44:49 2015 From: kmsujit at gmail.com (Sujit K M) Date: Sat, 19 Sep 2015 13:14:49 +0530 Subject: [talk] In Contrast to BSD init, A history of modern init systems (1992-2015) In-Reply-To: References: <86y4g6rwvd.fsf@gmail.com> <864miqsx9q.fsf@gmail.com> Message-ID: On Sat, Sep 19, 2015 at 1:08 PM, Malcolm Matalka wrote: > If you take a few minutes to read the website you'll notice that is imaging > software, not an init system. The website you want is: > > http://cr.yp.to/daemontools.html So how is this a init system. It is only a way to Manage UNIX Services. Quote from the home page. "What is it? daemontools is a collection of tools for managing UNIX services. supervise monitors a service. It starts the service and restarts the service if it dies. Setting up a new service is easy: all supervise needs is a directory with a run script that runs the service. multilog saves error messages to one or more logs. It optionally timestamps each line and, for each log, includes or excludes lines matching specified patterns. It automatically rotates logs to limit the amount of disk space used. If the disk fills up, it pauses and tries again, without losing any data." Regards, > > Den 19 sep 2015 09:31 skrev "Sujit K M" : >> >> http://www.daemon-tools.cc/support/faq#free_or_not >> >> On Sat, Sep 19, 2015 at 12:36 PM, Malcolm Matalka >> wrote: >> > Sujit K M writes: >> > >> > >> >> >> >> Please stop promoting proprietary solutions to the list. >> >> >> > >> > daemontools is open source and has been modified/extended in multiple >> > ways (daemontools-encore, runit). I'm not sure how I am promoting a >> > proprietary solution, please enlighten me? >> >> _______________________________________________ >> talk mailing list >> talk at lists.nycbug.org >> http://lists.nycbug.org/mailman/listinfo/talk From mmatalka at gmail.com Sat Sep 19 03:49:17 2015 From: mmatalka at gmail.com (Malcolm Matalka) Date: Sat, 19 Sep 2015 09:49:17 +0200 Subject: [talk] In Contrast to BSD init, A history of modern init systems (1992-2015) In-Reply-To: References: <86y4g6rwvd.fsf@gmail.com> <864miqsx9q.fsf@gmail.com> Message-ID: It is not an init system, as I said in the first email you responded to, however multiple init systems have drawn inspiration directly from it such as runit and s6. It is also covered in the initial link that kicked off this discussion due to its influence. It would be appreciated if you read the content being discussed, and your own links, better, especially when you take on an aggressive and authoritative tone. Thanks. Den 19 sep 2015 09:45 skrev "Sujit K M" : > On Sat, Sep 19, 2015 at 1:08 PM, Malcolm Matalka > wrote: > > If you take a few minutes to read the website you'll notice that is > imaging > > software, not an init system. The website you want is: > > > > http://cr.yp.to/daemontools.html > > So how is this a init system. It is only a way to Manage UNIX > Services. Quote from the home page. > > "What is it? > > daemontools is a collection of tools for managing UNIX services. > > supervise monitors a service. It starts the service and restarts the > service if it dies. Setting up a new service is easy: all supervise > needs is a directory with a run script that runs the service. > > multilog saves error messages to one or more logs. It optionally > timestamps each line and, for each log, includes or excludes lines > matching specified patterns. It automatically rotates logs to limit > the amount of disk space used. If the disk fills up, it pauses and > tries again, without losing any data." > > Regards, > > > > > Den 19 sep 2015 09:31 skrev "Sujit K M" : > >> > >> http://www.daemon-tools.cc/support/faq#free_or_not > >> > >> On Sat, Sep 19, 2015 at 12:36 PM, Malcolm Matalka > >> wrote: > >> > Sujit K M writes: > >> > > >> > > >> >> > >> >> Please stop promoting proprietary solutions to the list. > >> >> > >> > > >> > daemontools is open source and has been modified/extended in multiple > >> > ways (daemontools-encore, runit). I'm not sure how I am promoting a > >> > proprietary solution, please enlighten me? > >> > >> _______________________________________________ > >> talk mailing list > >> talk at lists.nycbug.org > >> http://lists.nycbug.org/mailman/listinfo/talk > > _______________________________________________ > talk mailing list > talk at lists.nycbug.org > http://lists.nycbug.org/mailman/listinfo/talk > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kmsujit at gmail.com Sat Sep 19 03:56:53 2015 From: kmsujit at gmail.com (Sujit K M) Date: Sat, 19 Sep 2015 13:26:53 +0530 Subject: [talk] In Contrast to BSD init, A history of modern init systems (1992-2015) In-Reply-To: References: <86y4g6rwvd.fsf@gmail.com> <864miqsx9q.fsf@gmail.com> Message-ID: On Sat, Sep 19, 2015 at 1:19 PM, Malcolm Matalka wrote: > It is not an init system, as I said in the first email you responded to, > however multiple init systems have drawn inspiration directly from it such > as runit and s6. It is also covered in the initial link that kicked off > this discussion due to its influence. > Quote You Below in your most recent Mail "If you take a few minutes to read the website you'll notice that is imaging software, not an init system" ^^^^^^^^^^^^^^^^ > It would be appreciated if you read the content being discussed, and your > own links, better, especially when you take on an aggressive and > authoritative tone. Any opensource development will have a aggressive look at a open place. If you please search google for "daemon tools" it gets "http://www.daemon-tools.cc" If you want people to look at every bit of information before asking questions, you won't find it here. > > Thanks. > > Den 19 sep 2015 09:45 skrev "Sujit K M" : >> >> On Sat, Sep 19, 2015 at 1:08 PM, Malcolm Matalka >> wrote: >> > If you take a few minutes to read the website you'll notice that is >> > imaging >> > software, not an init system. The website you want is: >> > >> > http://cr.yp.to/daemontools.html >> >> So how is this a init system. It is only a way to Manage UNIX >> Services. Quote from the home page. >> >> "What is it? >> >> daemontools is a collection of tools for managing UNIX services. >> >> supervise monitors a service. It starts the service and restarts the >> service if it dies. Setting up a new service is easy: all supervise >> needs is a directory with a run script that runs the service. >> >> multilog saves error messages to one or more logs. It optionally >> timestamps each line and, for each log, includes or excludes lines >> matching specified patterns. It automatically rotates logs to limit >> the amount of disk space used. If the disk fills up, it pauses and >> tries again, without losing any data." >> >> Regards, >> >> > >> > Den 19 sep 2015 09:31 skrev "Sujit K M" : >> >> >> >> http://www.daemon-tools.cc/support/faq#free_or_not >> >> >> >> On Sat, Sep 19, 2015 at 12:36 PM, Malcolm Matalka >> >> wrote: >> >> > Sujit K M writes: >> >> > >> >> > >> >> >> >> >> >> Please stop promoting proprietary solutions to the list. >> >> >> >> >> > >> >> > daemontools is open source and has been modified/extended in multiple >> >> > ways (daemontools-encore, runit). I'm not sure how I am promoting a >> >> > proprietary solution, please enlighten me? >> >> >> >> _______________________________________________ >> >> talk mailing list >> >> talk at lists.nycbug.org >> >> http://lists.nycbug.org/mailman/listinfo/talk >> >> _______________________________________________ >> talk mailing list >> talk at lists.nycbug.org >> http://lists.nycbug.org/mailman/listinfo/talk From mmatalka at gmail.com Sat Sep 19 04:11:55 2015 From: mmatalka at gmail.com (Malcolm Matalka) Date: Sat, 19 Sep 2015 10:11:55 +0200 Subject: [talk] In Contrast to BSD init, A history of modern init systems (1992-2015) In-Reply-To: References: <86y4g6rwvd.fsf@gmail.com> <864miqsx9q.fsf@gmail.com> Message-ID: Den 19 sep 2015 09:57 skrev "Sujit K M" : > > On Sat, Sep 19, 2015 at 1:19 PM, Malcolm Matalka wrote: > > It is not an init system, as I said in the first email you responded to, > > however multiple init systems have drawn inspiration directly from it such > > as runit and s6. It is also covered in the initial link that kicked off > > this discussion due to its influence. > > > Quote You Below in your most recent Mail > > "If you take a few minutes to read the website you'll notice that is imaging > software, not an init system" > ^^^^^^^^^^^^^^^^ > > > It would be appreciated if you read the content being discussed, and your > > own links, better, especially when you take on an aggressive and > > authoritative tone. > > Any opensource development will have a aggressive look at a open place. > If you please search google for "daemon tools" it gets > "http://www.daemon-tools.cc" > If you want people to look at every bit of information before asking questions, > you won't find it here. > Ha-ha certainly not, there is too much to read. But looking at your own links would be a good start. For example, this conversation could have simply been "I found a proprietary thing called daemontools that is an imaging software suite, is this what you are talking about?". Then I'd say "no, it's harder to find than it should be here is the link..". And wouldn't that have been pleasant? Anyways, enjoy your weekend > > > > Thanks. > > > > Den 19 sep 2015 09:45 skrev "Sujit K M" : > >> > >> On Sat, Sep 19, 2015 at 1:08 PM, Malcolm Matalka > >> wrote: > >> > If you take a few minutes to read the website you'll notice that is > >> > imaging > >> > software, not an init system. The website you want is: > >> > > >> > http://cr.yp.to/daemontools.html > >> > >> So how is this a init system. It is only a way to Manage UNIX > >> Services. Quote from the home page. > >> > >> "What is it? > >> > >> daemontools is a collection of tools for managing UNIX services. > >> > >> supervise monitors a service. It starts the service and restarts the > >> service if it dies. Setting up a new service is easy: all supervise > >> needs is a directory with a run script that runs the service. > >> > >> multilog saves error messages to one or more logs. It optionally > >> timestamps each line and, for each log, includes or excludes lines > >> matching specified patterns. It automatically rotates logs to limit > >> the amount of disk space used. If the disk fills up, it pauses and > >> tries again, without losing any data." > >> > >> Regards, > >> > >> > > >> > Den 19 sep 2015 09:31 skrev "Sujit K M" : > >> >> > >> >> http://www.daemon-tools.cc/support/faq#free_or_not > >> >> > >> >> On Sat, Sep 19, 2015 at 12:36 PM, Malcolm Matalka < mmatalka at gmail.com> > >> >> wrote: > >> >> > Sujit K M writes: > >> >> > > >> >> > > >> >> >> > >> >> >> Please stop promoting proprietary solutions to the list. > >> >> >> > >> >> > > >> >> > daemontools is open source and has been modified/extended in multiple > >> >> > ways (daemontools-encore, runit). I'm not sure how I am promoting a > >> >> > proprietary solution, please enlighten me? > >> >> > >> >> _______________________________________________ > >> >> talk mailing list > >> >> talk at lists.nycbug.org > >> >> http://lists.nycbug.org/mailman/listinfo/talk > >> > >> _______________________________________________ > >> talk mailing list > >> talk at lists.nycbug.org > >> http://lists.nycbug.org/mailman/listinfo/talk > > _______________________________________________ > talk mailing list > talk at lists.nycbug.org > http://lists.nycbug.org/mailman/listinfo/talk -------------- next part -------------- An HTML attachment was scrubbed... URL: From christos at zoulas.com Sat Sep 19 09:45:42 2015 From: christos at zoulas.com (Christos Zoulas) Date: Sat, 19 Sep 2015 09:45:42 -0400 Subject: [talk] In Contrast to BSD init, A history of modern init systems (1992-2015) In-Reply-To: from Sujit K M (Sep 19, 9:31am) Message-ID: <20150919134542.B123A17FDAF@rebar.astron.com> On Sep 19, 9:31am, kmsujit at gmail.com (Sujit K M) wrote: -- Subject: Re: [talk] In Contrast to BSD init, A history of modern init syst | On Thu, Sep 17, 2015 at 12:54 AM, Malcolm Matalka wrote: | > | > I have not had a problem that these new systems solve either. I | > actually prefer daemontools out of all of these (not an init system, I | > know, but close enough for this discussion, I think), because it's very | > simple. In the case of a server, I'm not sure why one would want | > something more than something like daemontools. I can see an argument | > for something more sophisticated for a desktop environment but I'm not | > sure what that would really look like. I'm pretty biased in my opinion | > here though, so YMMV. | | Please stop promoting proprietary solutions to the list. I think you are confusing the disk utilitities stuff (unrelated to the discussion but the first hit with google): http://www.daemon-tools.cc/home with: https://en.wikipedia.org/wiki/Daemontools which is relevant, ancient, and free... christos From raulcuza at gmail.com Mon Sep 21 11:09:40 2015 From: raulcuza at gmail.com (Raul Cuza) Date: Mon, 21 Sep 2015 11:09:40 -0400 Subject: [talk] In Contrast to BSD init, A history of modern init systems (1992-2015) In-Reply-To: <20150919134542.B123A17FDAF@rebar.astron.com> References: <20150919134542.B123A17FDAF@rebar.astron.com> Message-ID: This thread is exhibiting some of the communication problems that plague init tools and service coordination. (The first sentence is meant as humor and not a judgement of anyone's contribution to the thread so far. If you take offense, please feel free to fork it and release a funnier version.) Back to the topic at hand: which is what exactly? I posted a history of init systems. As the discussion evolved, it became apparent that there is disagreement by what init systems are supposed to do. Is the initiation system just for when the OS boots or is it a service coordinator that plays a continuous role? Thank you, Sujit, for sharing Jordan Hubbard's talk that elucidates a critical reason for this disagreement. The hardware and situations that operating system occupy today is remarkably different than 21 years ago. Traditionally a server gets installed on a machine and is brought up in a particular physical environment with a set of configurations and left to run. The init system in this case makes sure the server's daemons get started in the right order and then steps out of the way. This is the class of server I have managed in most of the work I've done and what I called "classical". A modern operating system cannot make the same assumptions that could be made 21 years ago. It might be installed on a USB stick that gets moved to to different machines. It might be on hardware or virtual-hardware that gets put to sleep periodically (e.g. a laptop). Network interfaces may come and go while the server is running (e.g. USB Wi-Fi and Cellular). Isn't it the operating system's role in these situations to coordinate these changes? If you say yes to this then it follows that the 'init' service is not something that can happen at boot and then walk away. Now this is where I am stuck. How does BSD help software developers navigate all these complex events while giving them the freedom to use the wealth of useful tools that currently exist? It is wrong for our OS to dictate that all software on it must use $X configuration format and nothing else (where $X is whatever standard is chosen, for instance XML or JSON). But if the OS is going to offer coordination between services then there must be standards that they all use in order to reap the benefits of the coordination service. And configuration formats is just one of many standards that a service coordination tool needs to be effective. Hubbard mentioned having BSD run on watches and phones, which I really could care less about since I don't administer or develop for these platforms. What I do want to do is to choose BSD for all the places I currently deploy servers, from virtual machines on developers laptops, to iron on a rack, and instances in other company's stacks. And apparently the 'classical' init system is one of the reasons this is not easy for me to do yet. No conclusions here, but something I will continue to think and talk about. This is a very interesting problem whose solution will benefit BSD's role in the tech world. Thank you for your contributions. Ra?l From pete at nomadlogic.org Mon Sep 21 16:58:58 2015 From: pete at nomadlogic.org (Pete Wright) Date: Mon, 21 Sep 2015 13:58:58 -0700 Subject: [talk] In Contrast to BSD init, A history of modern init systems (1992-2015) In-Reply-To: References: Message-ID: <56006F92.7050606@nomadlogic.org> On 09/16/15 09:56, Raul Cuza wrote: > In light of the recent discussion on *BSD and init system, I thought > this history of modern init systems a interesting contrast: > http://blog.darknedgy.net/technology/2015/09/05/0/ > > By definition of "modern", the BSD style init is the "classical" that > these systems are not. Maybe I don't understand the problems these > alternatives are trying to solve sufficiently. If you can shed some > light on it, I'd love to hear it. > > What I like most about the history is that most of those attempts at > improvements have not impacted the systems I manage (conveniently > ignoring the OS X fleets I've been in charge of at various times). For > me, the classical solution gets the job done. > Hy Raul I agree with you for sure. I have often thought about this going back to when I had to support some production systems that were using daemontools as their service monitor some time ago. (FWIW - i think calling things like daemontools, upstart, systemd, etc. service monitors is more descriptive about their goals than calling them a new implementations of BSD or SysV init.) a couple of use-cases I've seen for these process supervisors: - developer has written a daemonized processes. it's buggy and crashes periodically, but we don't have resources at the moment to fix the bug causing the daemon to crash because corporations are bad and should feel bad. we used daemontools to monitor that the deamon was running, and had it automatically restart if it crashed. - a vendor has supplied a suite of tools that are very complex to manage, and have a complicated hierarchy of services that need to be running before they can start themselves. for example - my application server needs the local oracle DB server up first, which depends on some iSCSI volumes to get mounted which depends on a functioning IP stack etc. some of these process supervisors can make it easy(?) to manage these poorly thought-out (and inevitably proprietary) software suites. As you'll note - neither of these use-cases were about a system monitor buying me something i couldn't accomplish with standard sysv or bsd init. IMHO they are more often used to bury your org's technical debt - which i reckon is probably the worst thing you can do with tech debt. I'm sure there are some very valid use-cases for these system monitors that i'm not thinking of, but from my own experience i've never really seen the benefit. anywho those are my two bits on this. -pete -- Pete Wright pete at nomadlogic.org twitter => @nomadlogicLA From edlinuxguru at gmail.com Mon Sep 21 18:02:35 2015 From: edlinuxguru at gmail.com (Edward Capriolo) Date: Mon, 21 Sep 2015 18:02:35 -0400 Subject: [talk] In Contrast to BSD init, A history of modern init systems (1992-2015) In-Reply-To: <56006F92.7050606@nomadlogic.org> References: <56006F92.7050606@nomadlogic.org> Message-ID: " developer has written a daemonized processes. it's buggy and crashes periodically, but we don't have resources at the moment to fix the bug causing the daemon to crash because corporations are bad and should feel bad. we used daemontools to monitor that the deamon was running, and had it automatically restart if it crashed." ' We all have done this, but this is a very dangerous path. I worked at a place where I was a sysadmin. I was BLAMED because my 'restart processes' failed to properly restart 'buggy developer process x'. I always consider this the first step on the highway to hell (aka Janitor ops). Once the enterprise adopts the notion that 'smart developer types' are 'too busy' to make processes that do not crash or do not fill disk with logs, all the crap work falls on ops. Soon people sending you tar files because they 'too busy to make installer'. Flashbacks sorry. In the end having something restart downed processes is smart but if anything starts crashing repeatedly something need to be done. IE 1 random crash a week means someone go fix it! On Mon, Sep 21, 2015 at 4:58 PM, Pete Wright wrote: > > > On 09/16/15 09:56, Raul Cuza wrote: > > In light of the recent discussion on *BSD and init system, I thought > > this history of modern init systems a interesting contrast: > > http://blog.darknedgy.net/technology/2015/09/05/0/ > > > > By definition of "modern", the BSD style init is the "classical" that > > these systems are not. Maybe I don't understand the problems these > > alternatives are trying to solve sufficiently. If you can shed some > > light on it, I'd love to hear it. > > > > What I like most about the history is that most of those attempts at > > improvements have not impacted the systems I manage (conveniently > > ignoring the OS X fleets I've been in charge of at various times). For > > me, the classical solution gets the job done. > > > > Hy Raul I agree with you for sure. I have often thought about this > going back to when I had to support some production systems that were > using daemontools as their service monitor some time ago. > > (FWIW - i think calling things like daemontools, upstart, systemd, etc. > service monitors is more descriptive about their goals than calling them > a new implementations of BSD or SysV init.) > > a couple of use-cases I've seen for these process supervisors: > > - developer has written a daemonized processes. it's buggy and crashes > periodically, but we don't have resources at the moment to fix the bug > causing the daemon to crash because corporations are bad and should feel > bad. we used daemontools to monitor that the deamon was running, and > had it automatically restart if it crashed. > > - a vendor has supplied a suite of tools that are very complex to > manage, and have a complicated hierarchy of services that need to be > running before they can start themselves. for example - my application > server needs the local oracle DB server up first, which depends on some > iSCSI volumes to get mounted which depends on a functioning IP stack > etc. some of these process supervisors can make it easy(?) to manage > these poorly thought-out (and inevitably proprietary) software suites. > > > As you'll note - neither of these use-cases were about a system monitor > buying me something i couldn't accomplish with standard sysv or bsd > init. IMHO they are more often used to bury your org's technical debt - > which i reckon is probably the worst thing you can do with tech debt. > > I'm sure there are some very valid use-cases for these system monitors > that i'm not thinking of, but from my own experience i've never really > seen the benefit. > > anywho those are my two bits on this. > -pete > > -- > Pete Wright > pete at nomadlogic.org > twitter => @nomadlogicLA > > _______________________________________________ > talk mailing list > talk at lists.nycbug.org > http://lists.nycbug.org/mailman/listinfo/talk > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pete at nomadlogic.org Mon Sep 21 18:07:11 2015 From: pete at nomadlogic.org (Pete Wright) Date: Mon, 21 Sep 2015 15:07:11 -0700 Subject: [talk] In Contrast to BSD init, A history of modern init systems (1992-2015) In-Reply-To: References: <56006F92.7050606@nomadlogic.org> Message-ID: <56007F8F.8070201@nomadlogic.org> On 09/21/15 15:02, Edward Capriolo wrote: > " developer has written a daemonized processes. it's buggy and crashes > periodically, but we don't have resources at the moment to fix the bug > causing the daemon to crash because corporations are bad and should feel > bad. we used daemontools to monitor that the deamon was running, and > had it automatically restart if it crashed." > > ' We all have done this, but this is a very dangerous path. I worked at > a place where I was a sysadmin. I was BLAMED because my 'restart > processes' failed to properly restart 'buggy developer process x'. I > always consider this the first step on the highway to hell (aka Janitor > ops). Once the enterprise adopts the notion that 'smart developer types' > are 'too busy' to make processes that do not crash or do not fill disk > with logs, all the crap work falls on ops. Soon people sending you tar > files because they 'too busy to make installer'. > > Flashbacks sorry. > > In the end having something restart downed processes is smart but if > anything starts crashing repeatedly something need to be done. IE 1 > random crash a week means someone go fix it! oh yea i %100 agree with you about how horrible this use-case is. as a sysadmin i'm sure you are also familiar with inheriting huge/complex/horribly-written systems which was held together by duct-tape, daemontools and nightmare inducing /bin/sh scripts. this was one of those guys. and after going through that rodeo at several different jobs i came up with my opinion that technical debt should *not* be hidden, but put front and center so that it gets addressed :) -pete -- Pete Wright pete at nomadlogic.org twitter => @nomadlogicLA From george at ceetonetechnology.com Wed Sep 23 12:49:54 2015 From: george at ceetonetechnology.com (George Rosamond) Date: Wed, 23 Sep 2015 12:49:54 -0400 Subject: [talk] MakerFaire this weekend Message-ID: <5602D832.7030303@ceetonetechnology.com> I assume a number of people on talk@ will be at MakerFaire at the Queens Hall of Science this weekend. I'll be there both days. Browsing through the list of 'makers' this year, it seems a bit weaker with ARM and MIPS manufacturers, although I think it's the first time Freescale will be there. g From john.joe.villa at gmail.com Wed Sep 23 14:17:59 2015 From: john.joe.villa at gmail.com (John Villa) Date: Wed, 23 Sep 2015 14:17:59 -0400 Subject: [talk] MakerFaire this weekend In-Reply-To: <5602D832.7030303@ceetonetechnology.com> References: <5602D832.7030303@ceetonetechnology.com> Message-ID: See ya there :) This is always fun! On Wed, Sep 23, 2015 at 12:49 PM, George Rosamond < george at ceetonetechnology.com> wrote: > I assume a number of people on talk@ will be at MakerFaire at the Queens > Hall of Science this weekend. > > I'll be there both days. > > Browsing through the list of 'makers' this year, it seems a bit weaker > with ARM and MIPS manufacturers, although I think it's the first time > Freescale will be there. > > g > > _______________________________________________ > talk mailing list > talk at lists.nycbug.org > http://lists.nycbug.org/mailman/listinfo/talk > -------------- next part -------------- An HTML attachment was scrubbed... URL: