Re: Trimming a diskless distribution
On 10/16/2018 2:23 PM, Brett Lymn wrote: On Mon, Oct 15, 2018 at 06:44:30PM -0700, Don NetBSD wrote: You're used to dealing with "computers" where you CAN change a piece of software AFTER release. I deal with devices/appliances where the cost of upgrading the device far exceeds the cost of the device (and comes at a huge "reputation cost" in the eyes of the user: "You mean, this device has been BROKEN all of this time?") Yes, I figured that was what you were doing but if there is any chance that your product will be featured in the technology news channels for having vulnerabilities that allow it to be used by bot herders or crypto currency miners it would be possibly more embarressing... IME, that happens when folks embrace some (large) piece of software (e.g., a Linux kernel) that they don't completely understand -- because it is never formally defined, in its entirety, in a way that those deploying it can grok. OTOH, when you develop a codebase specifically FOR a particular product, you avoid the risk of adding "cruft" to cover features and mechanisms that you aren't using. I'm looking to combine the best of both worlds -- use NetBSD to give me a flexible hardware platform that I can morph to suit the needs of proposed products (e.g., USB peripherals instead of having those same devices "on board" in a production version) at a prototype/proof-of-concept level; but the established (and "understood") codebase that we're already supporting for an eventual product deployment to free us from having to "support" a NetBSD implementation.
Re: Trimming a diskless distribution
On Mon, Oct 15, 2018 at 06:44:30PM -0700, Don NetBSD wrote: > > You're used to dealing with "computers" where you CAN change a piece of > software AFTER release. I deal with devices/appliances where the cost of > upgrading the device far exceeds the cost of the device (and comes at > a huge "reputation cost" in the eyes of the user: "You mean, this device > has been BROKEN all of this time?") > Yes, I figured that was what you were doing but if there is any chance that your product will be featured in the technology news channels for having vulnerabilities that allow it to be used by bot herders or crypto currency miners it would be possibly more embarressing... > I'm exploiting the fact that I can throw a NetBSD system onto some COTS > hardware (without requiring it to be a "PC"), embelish it with outboard > devices (so I don't have to get monies approved to build prototypes) and > pitch a proof of concept prototype to Management -- to fund REAL > development efforts. > Yes, this is not the first time that has been done. Good Luck :) -- Brett Lymn Let go, or be dragged - Zen proverb.
Re: Trimming a diskless distribution
On 10/14/2018 2:36 PM, Brett Lymn wrote: I've been "manually" invoking everything that I want/need to run and capturing any errors logged to sort out what might be missing. Right - atf can automate this bit for you. If you are doing a customised build then you will want to do this agin if/when you update to make sure things are not broken afterwards. It means you can validate things in a consistent and repeatable manner. I think that's more than I need. I'm going to pick *a* release and stick with it (for a very long time -- updates will be difficult). The bigger concern is deciding that I need to add some particular binary to this "distribution". Adding shouldn't break anything that already works but could require additional dependencies that haven't been present, prior to that point. OK, if you say so but manually bashing through all the tests time after time just to track down some obscure crash is pretty tedious in my mind. You probably should think seriously about maintaining the image even if it is for back-porting security updates. You're used to dealing with "computers" where you CAN change a piece of software AFTER release. I deal with devices/appliances where the cost of upgrading the device far exceeds the cost of the device (and comes at a huge "reputation cost" in the eyes of the user: "You mean, this device has been BROKEN all of this time?") I'm exploiting the fact that I can throw a NetBSD system onto some COTS hardware (without requiring it to be a "PC"), embelish it with outboard devices (so I don't have to get monies approved to build prototypes) and pitch a proof of concept prototype to Management -- to fund REAL development efforts. The NetBSD variant will then be unceremoniously scrapped (it would be silly to deploy something as big and bulky and likely to need continued updates in the future when we have our own codebase that addresses our needs far more precisely). I just have to ensure that the NetBSD-variant of the device "appears" to perform all of the basic functions (so Management can actually "tickle" the prototype and elicit the expected responses/behaviors) and have a valid explanation for those that the device can't perform.
Re: Trimming a diskless distribution
On Wed, Oct 10, 2018 at 07:13:41PM -0700, Don NetBSD wrote: > On 10/8/2018 2:10 PM, Brett Lymn wrote: > > > >For your purposes surely either just testing on loopback or on the local > >interface from the machine would be sufficient? You just wanted to make > >sure things start. > > Yes, but you have to arrange for all of those "things" to actually GET > started. And, the bigger problem, if they when invoked, there's > very little to help you figure out what they might be missing. > Well, that is what atf would be for. Do you know about anita? This is what the project uses to test the installer. If you automate the running ot the tests then it makes the "run, fail, fix, rins, repeat" process a lot easier. > You can look at the .so's that are linked to a (non-static) binary > and arrange for them to be present. But, if they exec something else, > in turn, then you have to arrange for those binaries (and their > dependencies) to be present. > Right, a shell script and ldd will help you pull ann the shared library dependencies. > Ideally, I'd like something like the "required to run" explicit dependency > specification in pkgsrc. > > [Yes, I realize this is asking a lot. So, I'm looking for a reliable way > of MANUALLY ascertaining these dependencies without having to rely on an > intimate knowledge of "how things work"] > Yes, it is asking a lot. I don't think you will find what you are looking for. Maintaing that sort of dependency list is a lot of work (as you have found) and there really is little gain for the NetBSD project as a whole to do this. > > > >If you want to really test externally then you could use qemu to build a > >test virtual machine and use the host at the "external" machine. > > I'm only looking to "test" to the extent that nothing SIGSEGV's or > otherwise crashes because I failed to include something that it needed > in the target filesystem. I assume that if I've got everything in > place, it "will work". > Yep, just opening the port of a network facing service will do that. > >>I've been "manually" invoking everything that I want/need to run and > >>capturing any errors logged to sort out what might be missing. > > > >Right - atf can automate this bit for you. If you are doing a > >customised build then you will want to do this agin if/when you update > >to make sure things are not broken afterwards. It means you can > >validate things in a consistent and repeatable manner. > > I think that's more than I need. I'm going to pick *a* release > and stick with it (for a very long time -- updates will be difficult). > The bigger concern is deciding that I need to add some particular > binary to this "distribution". Adding shouldn't break anything > that already works but could require additional dependencies that > haven't been present, prior to that point. > OK, if you say so but manually bashing through all the tests time after time just to track down some obscure crash is pretty tedious in my mind. You probably should think seriously about maintaining the image even if it is for back-porting security updates. > To repeat/summarize, my approach, thus far, has been to PXE boot a kernel > and let it NFS mount a remote filesystem that is initially empty. Then, > examine the errors that are generated and start adding stuff to that > file system to eliminate each error -- which inevitably exposes another > error, etc. > > Once the system made it to single user, I continued the process after > telling > it to go multiuser. > > Once it could correctly get to multiuser, THEN I started looking at the > additional programs that I wanted present -- adding each, individually; > invoking them, manually; then pacifying the errors that were thrown. > all of which atf can do for you... look for "netbsd anita" -- Brett Lymn Let go, or be dragged - Zen proverb.
Re: Trimming a diskless distribution
On 10/8/2018 2:10 PM, Brett Lymn wrote: On Sun, Oct 07, 2018 at 06:47:58PM -0700, Don NetBSD wrote: I don't think so. E.g., anything that relies on (or supports) remote clients/services would require some explicit action at a remote node to exercise those services. For your purposes surely either just testing on loopback or on the local interface from the machine would be sufficient? You just wanted to make sure things start. Yes, but you have to arrange for all of those "things" to actually GET started. And, the bigger problem, if they when invoked, there's very little to help you figure out what they might be missing. You can look at the .so's that are linked to a (non-static) binary and arrange for them to be present. But, if they exec something else, in turn, then you have to arrange for those binaries (and their dependencies) to be present. Ideally, I'd like something like the "required to run" explicit dependency specification in pkgsrc. [Yes, I realize this is asking a lot. So, I'm looking for a reliable way of MANUALLY ascertaining these dependencies without having to rely on an intimate knowledge of "how things work"] E.g., Will ftpd(8) get "tested" if it is invoked via inetd.conf(5)? (Ditto everything else therein). ftp localhost though you probably want something a bit more robust that fails within a timeout so the tests move on. If you want to really test externally then you could use qemu to build a test virtual machine and use the host at the "external" machine. I'm only looking to "test" to the extent that nothing SIGSEGV's or otherwise crashes because I failed to include something that it needed in the target filesystem. I assume that if I've got everything in place, it "will work". I've been "manually" invoking everything that I want/need to run and capturing any errors logged to sort out what might be missing. Right - atf can automate this bit for you. If you are doing a customised build then you will want to do this agin if/when you update to make sure things are not broken afterwards. It means you can validate things in a consistent and repeatable manner. I think that's more than I need. I'm going to pick *a* release and stick with it (for a very long time -- updates will be difficult). The bigger concern is deciding that I need to add some particular binary to this "distribution". Adding shouldn't break anything that already works but could require additional dependencies that haven't been present, prior to that point. The errors alone don't tell you *what* you need to add -- they just tell you that something is apparently "missing" or "not working properly". It then boils down to either having a familiarity with how each piece of code works *or* digging through the sources to see what MIGHT be the problem. Right, this bit will still need to be done manually but at least you can automate the running of the tests. Anyway, up to you how you do this. Just saying that this is the sort of stuff that atf is meant for To repeat/summarize, my approach, thus far, has been to PXE boot a kernel and let it NFS mount a remote filesystem that is initially empty. Then, examine the errors that are generated and start adding stuff to that file system to eliminate each error -- which inevitably exposes another error, etc. Once the system made it to single user, I continued the process after telling it to go multiuser. Once it could correctly get to multiuser, THEN I started looking at the additional programs that I wanted present -- adding each, individually; invoking them, manually; then pacifying the errors that were thrown. Because the order that I resolve errors has an impact on which NEW errors might (or might not!) arise, what I learn from creating one "distribution" (bad choice of terms) doesn't directly translate to creating a different distribution. E.g., an error thrown by PROGRAMA may be fixed by dragging libc into the target filesystem. Some time later, PROGRAMB may need something else -- but it ALSO needed libc and didn't complain about that because libc was already in place from PROGRAMA's needs! If the "next" distribution omits PROGRAMA, then my notes regarding PROGRAMB's needs (part of the new distribution) will be incomplete.
Re: Trimming a diskless distribution
On Sun, Oct 07, 2018 at 06:47:58PM -0700, Don NetBSD wrote: > > I don't think so. E.g., anything that relies on (or supports) remote > clients/services would require some explicit action at a remote node to > exercise those services. > For your purposes surely either just testing on loopback or on the local interface from the machine would be sufficient? You just wanted to make sure things start. > E.g., Will ftpd(8) get "tested" if it is invoked via inetd.conf(5)? > (Ditto everything else therein). > ftp localhost though you probably want something a bit more robust that fails within a timeout so the tests move on. If you want to really test externally then you could use qemu to build a test virtual machine and use the host at the "external" machine. > I've been "manually" invoking everything that I want/need to run and > capturing any errors logged to sort out what might be missing. Right - atf can automate this bit for you. If you are doing a customised build then you will want to do this agin if/when you update to make sure things are not broken afterwards. It means you can validate things in a consistent and repeatable manner. > The > errors alone don't tell you *what* you need to add -- they just tell you > that something is apparently "missing" or "not working properly". It > then boils down to either having a familiarity with how each piece of > code works *or* digging through the sources to see what MIGHT be the > problem. Right, this bit will still need to be done manually but at least you can automate the running of the tests. Anyway, up to you how you do this. Just saying that this is the sort of stuff that atf is meant for -- Brett Lymn Let go, or be dragged - Zen proverb.
Re: Trimming a diskless distribution
On 10/7/2018 2:07 PM, Brett Lymn wrote: On Thu, Oct 04, 2018 at 12:16:39PM -0700, Don NetBSD wrote: Of course, late bindings are a potential SNAFU in this approach -- unless I inherently know how to precipitate those events! Why not use the automated test framework to run everything you want to run? That should catch any errors for you. I don't think so. E.g., anything that relies on (or supports) remote clients/services would require some explicit action at a remote node to exercise those services. E.g., Will ftpd(8) get "tested" if it is invoked via inetd.conf(5)? (Ditto everything else therein). I've been "manually" invoking everything that I want/need to run and capturing any errors logged to sort out what might be missing. The errors alone don't tell you *what* you need to add -- they just tell you that something is apparently "missing" or "not working properly". It then boils down to either having a familiarity with how each piece of code works *or* digging through the sources to see what MIGHT be the problem.
Re: Trimming a diskless distribution
On Thu, Oct 04, 2018 at 12:16:39PM -0700, Don NetBSD wrote: > > Of course, late bindings are a potential SNAFU in this approach -- unless > I inherently know how to precipitate those events! Why not use the automated test framework to run everything you want to run? That should catch any errors for you. -- Brett Lymn Let go, or be dragged - Zen proverb.
Re: Trimming a diskless distribution
Don wrote: > To date, I've been exporting an *empty* filesystem and incrementally adding > stuff to it, based on errors detected in the process of going to singleuser... > and, likewise, proceeding on to multiuser. It's always nice to see that you are not alone :) -- caóc
Trimming a diskless distribution
A question similar, in spirit, to that of Cág ("Correct way to trim the
distribution?")
What's a "good" way to trim the exported filesystem for a diskless
system? (The goal being to eventually crunchgen a local system image
and eliminate the NFS mount entirely)
To date, I've been exporting an *empty* filesystem and incrementally adding
stuff to it, based on errors detected in the process of going to singleuser...
and, likewise, proceeding on to multiuser.
Of course, late bindings are a potential SNAFU in this approach -- unless
I inherently know how to precipitate those events!
