|
FlapYoJacks posted:https://gitlab.com/buildroot.org/buildroot/-/tree/master/package/flutter-engine?ref_type=heads congrats! also lol @ google releasing Yet Another Build System
|
# ? Oct 5, 2023 16:20 |
|
|
# ? Apr 28, 2024 03:56 |
|
YABS YABS YABS YABS
|
# ? Oct 5, 2023 16:24 |
|
Next up on the chopping block: Make Buildroot not suck with SELinux. Buildroot actually has decent SELinux support already! Currently, if a package has a selinux/ directory inside of it, the build system builds the policies in the selinux/ directory with refpolicy. However, there are three issues: 1) No packages currently have selinux/ directories. 2) Several packages need policies to work properly in enforcing mode. 3) Policies are always applied even when using a custom git version of refpolicy, which explicitly states, "if you use this, you are on your own." I submitted a patch to fix #3, and when applied, I will submit a good 10~ patches to fix 1 and 2. The end goal is that anyone, even without knowledge of SELinux, will be able to build a minimal system with enforcing turned on and have no denials in audit.log.
|
# ? Oct 9, 2023 18:54 |
|
FlapYoJacks posted:Next up on the chopping block: Make Buildroot not suck with SELinux. selinux on embedded linux always feels like that one task that no one wants to do because you have to cover all use cases so that denials won’t get triggered although I guess in this case, you can just run scenario tests for specific software and hope that covers it. Or, more likely, people create selinux profiles based on the software they’re shipping because then any unused features may simply not work which significantly reduces the attack surface.
|
# ? Oct 9, 2023 21:45 |
|
Writing an SELinux policy for every package in Buildroot sounds like my definition of hell
Poopernickel fucked around with this message at 22:55 on Oct 9, 2023 |
# ? Oct 9, 2023 22:49 |
|
SELinux is kind of a trash fire overall though tbh I just ship products with nonroot services and a bunch of systemd sandboxing. Nobody's hacked one of my designs yet
|
# ? Oct 9, 2023 22:57 |
|
sb hermit posted:Or, more likely, people create selinux profiles based on the software they’re shipping because then any unused features may simply not work which significantly reduces the attack surface. since this is the embedded thread, isn’t this what should be happening? it almost feels like the entire concept of saying “add SELinux policies to buildroot/yocto” is missing the point and the request makes it sound like you don’t want SELinux in the first place
|
# ? Oct 9, 2023 23:00 |
|
There is a minimal amount of effort being put into this. Not every package will have an selinux policy. So far there is: Busybox OpenSSH Systemd Audit SysVinit and a few others. Most of the policies are one or two lines. It’s enough to get a minimal system going in enforcing mode, that everyone would have to do. Nothing more, nothing less.
|
# ? Oct 10, 2023 07:27 |
|
hobbesmaster posted:since this is the embedded thread, isn’t this what should be happening? it almost feels like the entire concept of saying “add SELinux policies to buildroot/yocto” is missing the point and the request makes it sound like you don’t want SELinux in the first place I think SELinux is cool and good and a default or example policy would go a long way towards getting it adopted more widely. FlapYoJacks posted:There is a minimal amount of effort being put into this. Not every package will have an selinux policy. So far there is: yeah, this makes sense to me, although I figure busybox could easily be a bugbear if you really want to lock it down depending on what command is called (which starts to chip away at the spirit of busybox, in my opinion). Nevertheless, selinux on embedded is the lord’s work
|
# ? Oct 10, 2023 08:42 |
|
sb hermit posted:I think SELinux is cool and good and a default or example policy would go a long way towards getting it adopted more widely. Thanks! Buildroot also has an option to use a policy from git which disables any of the default buildroot policies. If you really want to get into the dirty nity-grity and make your own, you are free to do so!
|
# ? Oct 10, 2023 08:48 |
|
SELinux patches submitted.
|
# ? Oct 12, 2023 12:06 |
|
buildroot is simply the tits for kernel development god i love being able to just build an efi binary with my target kernel and tests all bundled up
|
# ? Oct 13, 2023 18:43 |
|
Tons more flutter work going on. I also figured out how to get sway working in Buildroot. I need to submit patches because in it's current form it's completely useless.
|
# ? Nov 22, 2023 02:36 |
|
our yocto image includes mariadb. is it possible to do first-time setup stuff like mariadb-install-db, setting a default password for root@localhost, etc. during image creation, instead of having to do it at first-boot on the target device?
|
# ? Nov 27, 2023 18:14 |
|
buildroot but in the australian sense
|
# ? Nov 27, 2023 18:15 |
|
Ciaphas posted:our yocto image includes mariadb. is it possible to do first-time setup stuff like mariadb-install-db, setting a default password for root@localhost, etc. during image creation, instead of having to do it at first-boot on the target device? can you not just grab the files from a target after setup? if there is something device specific then you’ll need to do something on first boot.
|
# ? Nov 27, 2023 19:34 |
|
yocto, passing around binaries while yelling "look how reproducible i am!" since whenever the gently caress
|
# ? Nov 27, 2023 19:42 |
|
just split this binary file up into 5 chunks, and bam file is 100% reproducible. you just cat together the 5 chunks!
|
# ? Nov 27, 2023 19:43 |
|
hobbesmaster posted:can you not just grab the files from a target after setup? if there is something device specific then you’ll need to do something on first boot.
|
# ? Nov 27, 2023 21:32 |
|
Ciaphas posted:I could; but it's not device-dependent, so I was hoping to just make it part of the initial image instead of having to do an intermediate and then the final image like that In these situations, either on Buildroot or Yocto, it's preferable to set up the DB on a device, dump the contents, and stuff it in an overlay. Then, have a startup script check to see if the DB is initialized, and if not, initialize the DB by using the dumped contents from earlier. It's a pain in the rear end to set up, but it's the best way I have found. That, or you can make a ${insert_language_of_choice} program that does that for you, but then you may have passwords laying around in plain text on your system (unless compiled, but then you have the passwords in source code, which is also meh.)
|
# ? Nov 27, 2023 21:40 |
|
FlapYoJacks posted:In these situations, either on Buildroot or Yocto, it's preferable to set up the DB on a device, dump the contents, and stuff it in an overlay. Then, have a startup script check to see if the DB is initialized, and if not, initialize the DB by using the dumped contents from earlier. It's a pain in the rear end to set up, but it's the best way I have found. That, or you can make a ${insert_language_of_choice} program that does that for you, but then you may have passwords laying around in plain text on your system (unless compiled, but then you have the passwords in source code, which is also meh.) (e) lol i suppose i could solve the pw part by putting the hash in the script instead of PASSWORD('blah'), now I think about it Ciaphas fucked around with this message at 22:12 on Nov 27, 2023 |
# ? Nov 27, 2023 22:08 |
|
Ciaphas posted:our yocto image includes mariadb. is it possible to do first-time setup stuff like mariadb-install-db, setting a default password for root@localhost, etc. during image creation, instead of having to do it at first-boot on the target device? I'd recommend making a package called something like mariadb-bonerlord-settings or something. The package can have a DEPENDS on mariadb-native, and then you can run your setup in the do_compile() stage and package the outputs. Then you can add your new package to the image you're trying to build. Probably you want the package to inherit allarch so that it's marked as architecture-independent. If you really want to do it in your image recipe, you can add a function to ROOTFS_POSTPROCESS_COMMAND and add this line to your image recipe: do_image[depends] += "mariadb-native:do_populate_sysroot" then you can use mariadb there instead of in a standalone settings package. Poopernickel fucked around with this message at 03:45 on Nov 28, 2023 |
# ? Nov 28, 2023 03:34 |
|
actually, I think Yocto runs pkg_postinst scripts in QEMU as part of the normal image build-flow. So maybe you can just add an extra post-install script in a bbappend or something.
Poopernickel fucked around with this message at 03:45 on Nov 28, 2023 |
# ? Nov 28, 2023 03:42 |
|
Yocto: there are 23435901 ways to do it
|
# ? Nov 28, 2023 03:44 |
|
Poopernickel posted:actually, I think Yocto runs pkg_postinst scripts in QEMU as part of the normal image build-flow. So maybe you can just add an extra post-install script in a bbappend or something. does it always do that? i wasn’t going to recommend that without knowing the target lol
|
# ? Nov 28, 2023 03:53 |
|
hobbesmaster posted:does it always do that? i wasn’t going to recommend that without knowing the target lol I think that's the standard flow these days, yeah. Yocto didn't always do that, but it's been true for the past couple of years. I wtfed about it the first time I noticed that qemu-native was being built along the path to core-image-minimal, and I went on a deep-dive to figure out why. op, I'd recommend the "make a package that uses mariadb-native to create your files" approach more than anything else I suggested. It's the cleanest imo Poopernickel fucked around with this message at 06:43 on Nov 28, 2023 |
# ? Nov 28, 2023 06:41 |
|
Ciaphas posted:our yocto image includes mariadb. is it possible to do first-time setup stuff like mariadb-install-db, setting a default password for root@localhost, etc. during image creation, instead of having to do it at first-boot on the target device? what did you wind up doing to solve this?
|
# ? Nov 29, 2023 17:26 |
|
Poopernickel posted:what did you wind up doing to solve this? Funny enough, back when I was an overworked, burnt out single man operation for an abusive company, I setup a postgresql server by running the disk image in qemu using a post image script. The script ran on first boot and self-deleted. Other than being a silly solution it worked fine. gently caress that company was otherwise.
|
# ? Nov 29, 2023 18:11 |
|
Poopernickel posted:what did you wind up doing to solve this? maybe it should have been pkg_postinst:mariadb-native(), i never quite remember which is which
|
# ? Dec 1, 2023 16:51 |
|
yocto is a gently caress
|
# ? Dec 1, 2023 16:53 |
|
so I'm working on an embedded Linux product, and we need to build out a bunch of testbenches that we can use for running automated tests. This is a hardware product, so each bench needs to have: - External power supply (UART or ethernet control) - Relay to connect some programming jumpers - Debug serial UART cable - Ethernet connection for SSH I'll be supporting 20-30 testbenches, so I expect there will be some differences in stuff like "bench #17 has a USB-controlled power supply, and bench #3 has a ethernet-controlled power supply. Debug UART is on /dev/ttyUSB0 for bench #2, but /dev/ttyUSB2 for bench #4." etc. How can I standardize these and provide a common interface to use in our test-suites? Is there anything out there that acts like "Hardware Abstraction Layer, but for testbench gear"?
|
# ? Jan 2, 2024 05:19 |
|
ansible
|
# ? Jan 2, 2024 05:24 |
|
bit of a shitpost answer though
|
# ? Jan 2, 2024 05:25 |
|
sb hermit posted:bit of a shitpost answer though Maybe not the right kind of thing. Ansible is an answer to "how do I manage a bunch of computers", but not really an answer to "how can I provide an abstraction around testbench hardware" Like, I assume that step-1 of most of our test suites will be "download a build, flash it onto the target hardware, then reboot". Say I have some external gear that handles power-cycling the device-under-test. So maybe I want my test-suite to make calls like "start DUT power, set to +12V". But if "start DUT power" is implemented differently on different computers, then I need an abstraction layer of some kind. I'm thinking something must already exist in this space - I can't believe that I have a unique problem here or anything. Poopernickel fucked around with this message at 06:46 on Jan 2, 2024 |
# ? Jan 2, 2024 06:34 |
|
Poopernickel posted:Maybe not the right kind of thing. Ansible is an answer to "how do I manage a bunch of computers", but not really an answer to "how can I provide an abstraction around testbench hardware" Yeah, that’s what I figured. It’s just that I think you can start building the skeleton of the test framework with ansible, and use tags or other mechanisms to dynamically determine how to tailor the playbook for each specific bench type. (to be honest, I am not an ansible expert.) This doesn’t address how those differences can be better managed, I admit. On the other hand, if this is a configuration management problem, there may not be many other solutions that fit your vision and you may want to adjust accordingly. So yeah. “ansible” is a shitpost answer. You might want to try this question in the linux thread, see if you get better answers.
|
# ? Jan 2, 2024 07:55 |
|
Pretty sure that other companies just use a hodgepodge of unreadable shell scripts with inscrutable timeout values and mainly written by one person who left six years ago and future changes were made by junior engineers in the interim.
|
# ? Jan 2, 2024 07:59 |
|
|
# ? Apr 28, 2024 03:56 |
|
sb hermit posted:Pretty sure that other companies just use a hodgepodge of unreadable shell scripts with inscrutable timeout values and mainly written by one person who left six years ago and future changes were made by junior engineers in the interim. yeah op i think this is your competition. especially if you're not gonna have the juice to be able to have a specific design implemented like a product. if you do have the juice for this, the right answer is definitely something like an SBC and a semicustom device tree that can force specific userspace bindings for things and then just write the software, a server/client or frontend/daemon architecture of some kind so you can manually control stuff if the ui doesn't present what you need. that's probably the right answer if you don't have the juice too you'll just have to abandon yourself to lots of config files keyed by machine type or some poo poo
|
# ? Jan 2, 2024 13:47 |