<    March 2017    >
Su Mo Tu We Th Fr Sa  
          1  2  3  4  
 5  6  7  8  9 10 11  
12 13 14 15 16 17 18  
19 20 21 22 23 _2_4 25  
26 27 28 29 30 31
00:00 alacerda joined
00:02 alacerda_ joined
00:09 alacerda__ joined
00:11 lesion joined
00:12 alacerda_ joined
00:20 gopar joined
00:20 blueness joined
00:21 alacerda__ joined
00:22 alacerda_ joined
00:25 Nobabs27 joined
00:28 sparklyballs joined
00:30 alacerda__ joined
00:31 alacerda_ joined
00:36 alacerda__ joined
00:43 gopar joined
00:45 alacerda_ joined
00:50 thohal joined
01:17 shad0 joined
01:21 LouisA joined
01:51 <shad0> anybody awake/around? I'm wondering if there's documentation about the configs=usb option of setup-alpine
01:56 <shad0> basically looking for a way to run from ram, loaded from a usb stick, with configs/overlays saved back to that usb stick...and data/var on a local ssd
02:27 t0mmy joined
02:36 Meths joined
02:39 Janhouse joined
02:42 thetrav joined
02:43 <thetrav> so I've found https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package and followed the instructions to modify the rsyslog package to include elasticsearch support... apkbuild -r seems to compile everything correctly, however I'm not sure how to test my built package
02:44 <prions> 15:56:57 < yGweSm1OzVHe> why don't u just replace syslinux with whatever arch is using in that setup?
02:44 <prions> i guess i could, whether thats less or more effort than any alternatives..
02:44 <prions> i can always find out though
02:46 <thetrav> erm, abuild -r, not apkbuild -r
02:48 <thetrav> ok, so there's a packages folder in my ~
02:48 <thetrav> it contains the apk's I want
02:48 <thetrav> so I guess I just install the apk from the file
02:57 s33se joined
03:04 ephemer0l joined
03:06 <prions> i may try an initramfs to load sshd + cryptsetup then i can just run the cryptsetup command over ssh directly
03:06 <prions> thanks
03:06 prions left
03:15 dirac1 joined
03:23 <TBB> I've never quite understood that security setup
03:26 <ephemer0l> https://bitbucket.org/piotrkarbowski/better-initramfs/
04:02 <kaniini> ephemer0l: interesting
04:02 <kaniini> maybe we should make an initramfs-generator virtual
04:02 cyborg-one joined
04:03 cyteen joined
04:03 <TemptorSent> kaniini: Most of the way to supporting that already :)
04:04 <kaniini> TemptorSent: i mean for installed systems
04:04 mguentner joined
04:04 <TemptorSent> kaniini: Yeah, me too :)
04:04 <kaniini> TemptorSent: mkimage is only for building live cd
04:04 <TemptorSent> kaniini: Nope, it builds kernel configs now too.
04:05 <TemptorSent> kaniini: mostly because update-kernel was incapible of filtering the content of modloop.
04:05 <kaniini> TemptorSent: sure, but i mean, mkimage is only meant for live media
04:05 <kaniini> TemptorSent: if you install alpine to a disk, it is not used
04:06 <TemptorSent> kaniini: Well, mkimage is, but the toolset can essentially build any part of it too with a little tweaking.
04:06 <TemptorSent> kaniini: Such as generating new overlays with configs for features baked in.
04:07 <kaniini> how does that involve an already installed system
04:07 <TemptorSent> kaniini: There really isn't any difference between a running system and an image except for a couple install directories and twiddlign mounts.
04:09 <TemptorSent> kaniini: mkimage is a misnomer at this point, as it can make any part of a filesystem you want, including a just a chroot or just a kernel/modloop/initramfs set.
04:10 systo joined
04:10 <kaniini> TemptorSent: okay and how do i use it to upgrade my pre-existing system
04:10 <kaniini> TemptorSent: how do i install new packages
04:10 <TemptorSent> kaniini: mkimage is a short script which processes the command line and invokes the build.
04:11 <ephemer0l> kaniini: I've been drawn here by finding this project's site. I've got issues with it's sponsor. more -offtopic related, though. So I thought I'd lurk here, but couldn't help but share that link.
04:11 <kaniini> you're either missing my point or you've created something that we will never merge
04:11 <kaniini> i'm not sure which ;)
04:11 <TemptorSent> kaniini: I haven't added the glue yet, but I plan to allow adding features to an existing system the same way they get added to the image -- an overlay
04:11 <ephemer0l> who's to say.
04:12 <kaniini> TemptorSent: and the people who do not want to use any of this stuff and just want to use apk add/del as they always have?
04:12 <TemptorSent> kaniini: That's why I was asking about the semantics of apk used in init .
04:12 <kaniini> none of my alpine installs except hypervisors run from ram or do any of that stuff
04:12 <kaniini> i just maintain them with apk
04:13 <kaniini> i would argue most alpine installs are this way
04:13 <TemptorSent> Go for it, it doesn't force anything, and the intent was for it to totally stand alone, just allow it to generate the necessary overlays and call apk.
04:13 <kaniini> oh
04:13 <kaniini> oh
04:13 <kaniini> oh
04:13 <kaniini> you're making something like debian's tasksel?
04:13 <TemptorSent> ? Sorry, haven't used that.
04:13 <kaniini> where you say "i want gnome" for example and it does the necessary steps
04:14 <kaniini> or "i want a voip server"
04:14 <kaniini> or whatever
04:14 <TemptorSent> Oh, sorta -- yeah, it can do that.
04:14 <kaniini> okay. you were scaring me
04:14 <kaniini> ephemer0l: what sponsor is that?
04:14 <TemptorSent> such as 'feature_ssh autostart autogenerate'
04:14 <ephemer0l> kaniini: the one listed on this project's site
04:15 <kaniini> ephemer0l: which?
04:15 <kaniini> oh
04:15 <ephemer0l> scaleway
04:15 <kaniini> oh
04:15 <kaniini> oh
04:15 <kaniini> i see
04:15 <kaniini> tbh
04:15 <kaniini> i do not even know why we have that page
04:15 <TemptorSent> It currently spits adds the required links to an overlay, generates keys, adds the appropriate set to the overlay, etc.
04:15 <kaniini> there's more than just those two companies sponsoring infrastructure
04:15 <kaniini> but hey, at least i do not have to tell you about how docker does not own alpine because it hired some alpine devs
04:15 <kaniini> ;)
04:16 <TemptorSent> To have it work on a live system, all you'd have to do is have it call "apk add $pkgs < $overlay.tmp"
04:16 <ephemer0l> kaniini: I find myself sharing this more and more... https://www.youtube.com/watch?v=PivpCKEiQOQ
04:17 <TemptorSent> It doesn't manage anything, it builds configurations.
04:17 <kaniini> TemptorSent: yeah i get it now
04:17 <ephemer0l> https://github.com/p8952/bocker
04:18 <TemptorSent> So updating a kernel / using a modulare initramfs generator would be a trivial extension, as it just replaces one function call.
04:19 <TemptorSent> About all it really tries to do tricky is allow overlays to be dep-based like openrc scripts so they apply correctly and have the right features enabled to work.
04:19 <kaniini> TemptorSent: yeah, so basically it's like tasksel but sane
04:20 <TemptorSent> That part I have a little clean-up work to do on, as I don't like the current repeated calls.
04:20 <TemptorSent> Take a look, you tell me if it's sane :)
04:21 <kaniini> well it seems to me like
04:21 <kaniini> these tools should be outside aports tree, in packages
04:21 <kaniini> if this is the new scope of them :)
04:21 <TemptorSent> It basically builds a system or parts thereof of your chosing based on profiles, features, and overlays (more or less) and having the implementations for things like bootloaders, image types, kernels, archs, abstracted out so they can be added and modified easily.
04:21 <kaniini> that seems like it is outside of the scope of the aports tree
04:22 <kaniini> :P
04:22 <TemptorSent> kaniini: That's the plan as soon as it reaches a point of reasonable usability and has had some review.
04:22 <TemptorSent> Right, it will be at the same strata as mkinitfs or the like.
04:22 <Xe> TemptorSent: why not develop it outside the tree and then intergate it in later?
04:22 <kaniini> because the original was already in the tree
04:22 <TemptorSent> Xe: It started as mkimage :)
04:23 <kaniini> ephemer0l: haha
04:23 <TemptorSent> Xe: Well, it started as me fixing alpine-iso to do what I needed... then I found out that was depreciated and got pointed at mkimage a few weeks ago.
04:24 <TemptorSent> It's gotten as bad as this :) https://github.com/TemptorSent/aports/tree/mkimage-refactor-scripts/scripts/mkimage
04:24 <kaniini> although i have a question
04:24 <kaniini> why shell for the profiles
04:24 <kaniini> why not just use yaml
04:24 <TemptorSent> Shoot.
04:24 <kaniini> and redo the whole thing in lua/python/whatever :p
04:25 <TemptorSent> because then A: I'd have to parse yaml and B: I couldn't get away with the disgusting but useful tricks I used and still have it work with essentially no added packages required for most operations.
04:27 <Xe> TemptorSent: write it in go and then ship a static binary
04:27 <TemptorSent> As it is, the script will happily run with nothing but busybox, apk, and the minimal crypto sig tools I believe if you redefine APK=apk rather than APK=abuild-apk
04:27 <TemptorSent> *LOL* you're sick Xe, you know that? :)
04:27 <Xe> actually, i am
04:28 <TemptorSent> What's next, haskel?
04:28 <Xe> it is packaged in testing
04:28 <TemptorSent> I'd go back to make before I did that!
04:28 <Xe> and you can build static binaries in haskell pretty easily thanks to musl
04:28 <TemptorSent> Actually, I had the make implemntation working surprisingly well.
04:28 <Xe> it's actually errily trivial
04:29 <TemptorSent> Xe, Yeah, I'm trying to get the entire image down to < 20MB
04:29 <Xe> nim?
04:29 <Xe> it shits out microbinaries
04:29 <TemptorSent> Actually, I'd love see a really stripped down setup for things like routers, but that might be asking too much.
04:30 <kaniini> alpine-base and iptables is too much for you?
04:30 <TemptorSent> Hmm, yeah.. but what's the chance that anyone who wants to make a custom whatever could figure it ou?
04:30 <Xe> unless you have the guile to do it in scheme
04:31 <TemptorSent> kaniini alpine-baselayout and deps are actually a bit too much for skel really :)
04:31 <TemptorSent> Xe: Punny one, ain't'cha?
04:32 <TemptorSent> I prefer my hsilop notation.
04:33 <Xe> you could also hand-write some assembly that calls into C functions to do things like yaml parsing
04:34 <Xe> TemptorSent: btw i am just pulling your leg, it's great that stuff that is so core can be improved like that :D
04:35 <TemptorSent> Xe: Don't tempt me -- I've written 8051 assembler to a uC using a basic loader and opcodes to write a new interrupt vector handler and monitor so I could use it for my own purposes :)
04:36 <kaniini> having a tasksel-like frontend to it would be a major win
04:36 <Xe> i've been wanting to make an EFI bootable ISO of alpine so I could unblock myself on getting alpine on my EFI-only boards, improvments to making an iso will be great
04:36 <TemptorSent> kaniini: It's somewhat like funtoo's extended profiles.
04:37 <Xe> what if this could be a feature of ACF?
04:37 <HazWard> I just realized there's only a version of py-gst for gstreamer 0.10 and none for gstreamer1, is there plans to add a package for it?
04:37 <TemptorSent> Xe: Take a look, I implemented what existed as far as getting the iso to utilize both the grub2 and isolinux loaders, so it shouldnt' be far off.
04:38 <TemptorSent> I haven't looked at ACF yet in any depth, but I suspect it would be able to dovetail nicely.
04:39 <TemptorSent> And I'm eventually going to canabalize mkinitfs into a plugin to make the granularity there much finer when desired
04:39 <TemptorSent> And I'm tempted to just fork lddtree and include my own version of that too, because it seems the upstream is constantly broken
04:40 <TemptorSent> But that can all just be done as a seperate dirctory to add to the core as needed if we want to trim it down.
04:41 <TemptorSent> Part of what I want to accomplish is to only distribute out whats needed to rebuild itself with an image.
04:41 <TemptorSent> Making regenerating an existing configuration with refreshed packages becomes simple and repeatable.
04:44 <TemptorSent> I haven't gottent there yet, but I'd like to have the build system make a tarball of everthing needed to make the target system and nothing else.
04:44 <kaniini> TemptorSent: okay but having something like tasksel would be nice :P
04:44 <TemptorSent> kaniini: Okay, what do we need for the desired functionality compared to what I have currently implemented?
04:45 <kaniini> https://www.howopensource.com/2013/05/install-lamp-server-using-tasksel-in-ubuntu-13-04-12-10-12-04/
04:45 <kaniini> not sure, but that's how it works
04:46 <TemptorSent> Oh, gotcha -- yeah, no purdy menu interface yet.
04:47 <TemptorSent> Actually, it already does a lot more than that it looks like, including allowing for selection between multiple provider for a featuer (dropbear/openssh) (isc(dhcpd/dhclient),dhcpcd(client only),busybox(udhcp[cd]) )
04:49 <TemptorSent> So mostly what it would need to do is spit out an overlay it looks like, and call apk for the packages.
04:49 <TemptorSent> Nothing preventing the current architecture from doing that with some very minor modifications.
04:50 <TemptorSent> But what I need to know to proceed is how apk handles the apk add ... --overlay-from-stdin < $ovlfiles construt.
04:52 <TemptorSent> Some of the overall logic should be cleaned up a bit to support that better, and I've been working my way in that direction, so it should actually be clean soon.
04:54 <TemptorSent> So I guess it's currently a file-driven tasksel + overlay builder + modloop generator + bootloader setup&configuartor + kernel configurator, but not yet mkinitfs.
04:56 <TemptorSent> Take a look at the tree and you'll see what I mean I think.
04:57 <TemptorSent> I'm currently working on splitting out the base overlay into a new overlays dir so we can easily support multiple base overlay types as needed and still use the rest of the profile (as you can with profile_base)
04:59 <TemptorSent> That way you can build the same effective configuration to run on anything from x86_64 iso to rpi, uboot, etc on arm, to whatever flavor of rootfs, container, or vm image you want.
05:01 <TemptorSent> And also build configs where no apk bootrepo is shipped and it's all fetched from within the initramfs.
05:02 dirac1 joined
05:03 <TemptorSent> It's actually simple enough to run in an initram fs, so a config could be built directly to $sysroot before switch_root.
05:04 <TemptorSent> ...and the overlays applied before openrc starts services.
05:07 <TemptorSent> Adding the ability in the overlays to check for running services would be easy enough where needed (such as building a DB image), so we can just dump them in where needed (overlayfs or bind mounts work)
05:07 <TemptorSent> Once loaded, dump the loader if you want :)
05:09 <kaniini> seems to me
05:09 <kaniini> we could use this to actually replace the current alpine installer (i.e. none)
05:11 <TemptorSent> Basically, anything you want for a plugin, just create a plugin file and define plugin_whatever.... then the plugin loader will automatically load files called whaterver_ as well as the rest, and will check all loaded files for functions called whatever_whatnot() {
05:13 <TemptorSent> kaniini: Yeah, right now I'm working on writng a lights-out (well almost, going to require customer to confirm wiping drives at boot) zfs based installer with preinitilized database, preestablished SSH keys, directory monitoring with incoming archive testing, extraction, ETL, and cold storage.
05:15 <TemptorSent> I'm currently writing the actual zpool/fs creation bit as a script specific to their system, but it could easily be generated with a little fiddling.
05:15 <TemptorSent> Once I've written the same thing more than two or three times, I write somethign to generate it for me :)
05:17 <TemptorSent> ZFS is a bit different than most FS configs, in that I'm not partitioning anything, rather essentially setting up a hierarchy of filesystems.
05:30 mikeee_ joined
05:32 <TemptorSent> fabled: Thank you! Can I use it to specify files NOT to be written regardles of origin as well if I wish? A general mask essentially?
05:33 <TemptorSent> fabled: And does it glob?
05:53 <fabled> TemptorSent, it can be used regardless of origin. it expects a filelist and is not a glob.
05:59 <TemptorSent> fabled: Thank you.
06:12 fabled joined
06:44 biax joined
06:44 <TemptorSent> kaniini: Ok, it looks like we can probably apply overlays sanely to an existing system, so that should be a matter of writing an imagetype plugin for it.
07:06 andypost joined
07:06 <TemptorSent> kaniini: So, what do we want in an installer, since most of it's there?
07:24 bougyman joined
07:24 bougyman joined
07:27 slukin joined
07:36 <kaniini> the stuff we have now in the kindof installer ;)
07:38 <clandmeter> kaniini, we are waiting for that gtk installer ;-)
07:39 <kaniini> well if there is a clean seperation between asking the needed questions, a gtk installer would be pretty easy
07:40 <clandmeter> I was referring to your latest apk-gui :)
07:40 gogoprog1 joined
07:41 <kaniini> working on kernel stuff this weekend sorry ;)
07:47 <kaniini> or maybe not
07:47 <kaniini> this PaX stuff is a mess
07:48 <kaniini> and the more i think about it, the more i come to the conclusion that for the typical deployment, application-level containment is a much larger win
07:48 <kaniini> PaX is great, but it becomes pointless the second you install PHP
07:49 <kaniini> also i found a lot of arguably bad code in PaX outside of the arch/x86 implementation
07:49 <kaniini> i would not trust PaX on parisc, for example ;)
07:49 <kaniini> it probably does not actually boot
07:55 nanohest joined
07:56 <TBB> I probably don't need to tell you they're technologies that complement eachother, PaX and containers.
07:56 <TBB> after all, you're the one hacking on it :)
07:56 <kaniini> you really don't
07:56 <kaniini> :D
07:57 <kaniini> however, PaX doesn't really do you much good when the real goal of an attacker is just to fuck up a website 99.9% of the time
07:57 <kaniini> :P
07:57 <kaniini> and having seen the sausage....
08:20 cyteen joined
08:38 Klowner_ joined
08:43 t0mmy joined
08:46 manacit joined
08:46 manacit joined
08:48 tmh1999 joined
08:56 kvda joined
08:59 manacit joined
08:59 manacit joined
09:23 fireglow joined
09:26 ageis joined
09:29 fireglow joined
09:33 royger joined
09:46 mikeee_ joined
09:47 stwa joined
09:47 JStoker joined
10:01 imv joined
10:07 Ayyad joined
10:09 fekepp joined
10:34 rollniak joined
10:46 <femme> kaniini, TBB what are you referring to that you are hacking on; something like what oz from subgraph os does?
10:47 <TBB> kaniini is looking at PaX
10:48 <TBB> since the situation with grsecurity is getting worse and worse, some mitigative steps need to be taken
10:48 <femme> yeah I'm aware of the situation, sad times
10:50 <femme> TBB, this is what I was talking about https://subgraph.com/sgos-handbook/sgos_handbook.shtml#sandboxing-applications-with-subgraph-oz
10:50 <femme> the kernel is grsec and it uses pax and container technologies to isolate apps
10:50 <TBB> not for long
10:51 <TBB> I'll have a look tho as soon as I get time, but the problem is that grsecurity won't be available soon
10:52 <femme> yeah I'm aware as are the subgraph devs, as are the hardened linux people ):
10:53 <TBB> ah, so there's some movement in the community!
10:53 <TBB> that's good to hear; losing grsecurity will be a huge loss
10:56 <femme> yeah the opensuse-gardened dev is also aware
10:57 <femme> I wonder what the KSPP are thinking
10:59 <TBB> probably where they can get the resources to do development of the same level and quality as grsec :)
11:00 <imv> there's a lot of sports-related spam on the forum, and nobody seems to pay any attention to it
11:04 <clandmeter> imv, can you provide me a link to it?
11:07 <clandmeter> imv, i cleaned it up.
11:09 <imv> clandmeter, thanks
11:10 <clandmeter> if there are users that often visit the forum and would like to help maintain it, please drop an email to alpine-infra@alpinelinux.org
11:11 <clandmeter> for ppl who dont like mailing lists, you can also PM me.
11:28 blueness joined
11:32 blueness joined
11:41 blueness joined
11:47 xsteadfastx joined
12:00 BitL0G1c joined
12:03 nanohest joined
12:25 joshwget joined
12:27 aw1 joined
12:41 sparklyballs joined
12:52 lesion joined
12:54 mikeee_ joined
12:59 blueness joined
13:00 nanohest joined
13:05 fireglow joined
13:07 lesion joined
13:10 dlewen joined
13:13 Kruppt joined
13:17 farosas joined
13:45 imv joined
13:54 imv joined
14:02 minimalism joined
14:06 o_be_one joined
14:07 sparklyballs joined
14:20 chapui_s joined
14:27 chapui_s joined
14:30 cyborg-one joined
14:31 sparklyballs joined
14:33 blueness joined
14:50 blueness joined
14:54 Skele joined
15:15 czart_ joined
15:25 ChrisRut_ joined
15:26 <ChrisRut_> Where can I go to find out information about how Alpine linux is built? Specifically I am trying to figure out if Alpine linux was built on-top-of Busybox or if it was completely built from the ground up?
15:38 stwa joined
15:50 <kaniini> built from ground up -- we just use busybox for /bin/ls and so on
15:50 thohal joined
16:10 tanxin joined
16:14 mikeee_ joined
16:16 Lord joined
16:16 mmlb joined
16:16 blackwind_123 joined
16:19 dlaube joined
16:33 Klowner joined
16:45 rollniak joined
17:07 <Klowner> man, this stupid zfs/docker issue is driving me bonkers
17:10 thohal joined
17:10 gopar joined
17:17 fabled joined
17:35 <Klowner> there's gotta be a guide for writing openrc init scripts somewhere..
17:41 <mmlb> TemptorSent: you around?
17:42 <mmlb> Klowner: what sort of docker/zfs issue are you having?
17:43 <Klowner> https://github.com/docker/docker/issues/24403
17:43 <Klowner> failing to destroy the zfs dataset because it's "in use"
17:43 <Klowner> can't delete until dockerd is restarted
17:44 <Klowner> looks like running dockerd with `unshare -m` might fix it?
17:45 <mmlb> Klowner: not sure, yeah I have run into those same issues. I've also done `unmount /var/lib/docker/zfs` then `zfs unmount` too, docker wasn't unmount the zfs subdir for some reason
17:45 <ChrisRut> Is Alpine affected by this CVE: https://vuldb.com/?id.96893 If so is it being tracked somewhere?
17:46 <dalias> it was but that's old
17:46 <TemptorSent> Hi mmlb, how's it going?
17:46 <dalias> the date on it is wrong
17:47 <mmlb> TemptorSent: o/ pretty good yourself? Saw that you added some cross-arch fixes.
17:47 <dalias> looks like a crappy vuln-scraping site
17:47 <_ikke_> ChrisRut: https://github.com/alpinelinux/aports/commit/f23c8c854458f4ed03157bba8603ce1248c34d3a
17:48 <TemptorSent> mmlb: I had it building aarch64 uboot images happily until I went and created my own local repo for my work on x86_64 -- now apk pukes out a warning that breaks the pipe every time I try to pull packages on aarch64 | tar
17:48 <TemptorSent> mmlb: It should still work as long as you don't have my particular flavor of hell :)
17:49 <mmlb> ohh nice, I'll definitely give that a try then
17:49 <mmlb> heh
17:49 <TemptorSent> mmlb; Any other bootloaders should work too, but haven't been tested.
17:50 <mmlb> TemptorSent: I come to you today in search of mkimage.sh generating just kernel and initramfs for ramdisk use only any thoughts?
17:50 <odc> what the hell is an "Integer buffer overflow" ?
17:50 <odc> it's either one or the other
17:50 <TemptorSent> mmlb: And I created a skel profile that you should be able to use as the base for whaever you want.
17:51 <mmlb> TemptorSent: oic minirootfs?
17:51 <TemptorSent> mmlb: I haven't explicitly made it do that yet, but if you give it a profile it will spit out the necessary files in the workdir.
17:52 <zhasha> dalias> the date on it is wrong
17:52 <TemptorSent> mmlb: Basically, but it's a normal profile and can be used by others.
17:52 <zhasha> You don't say. It's not even undecember yet
17:52 <scv> odc: TRE & musl libc regex integer overflows in buffer size computations
17:53 <scv> http://www.openwall.com/lists/oss-security/2016/10/19/10
17:53 <mmlb> TemptorSent: I'll mess with it now. I'm trying to update our pxe booting alpine from 3.2.2 to 3.5.2 for x86_64, but am stuck trying to get udhcp to work
17:53 <odc> that's clearer. Thanks scv
17:53 <scv> presumably as it's an older vuln it's patched
17:53 <ChrisRut> Thanks _ikke_
17:55 <mmlb> TemptorSent: I've got 2 use cases. 1st is boot with packer, install docker and build an image. Second is pxe boot on host, install docker and use said image to install os to disk, reboot
17:55 <TemptorSent> mmlb: Oh, yeah - take a look at features/dhcp -- it should be able to autostart udhcpc for you.
17:55 <mmlb> for x86_64 and aarch64
17:55 <mmlb> will do
17:55 <TemptorSent> mmlb: Why do you need the docker image to install the os on disk?
17:56 <mmlb> idk, thats just the way things were done when I got on board here. No real reason why I can't do it from alpine, but 1 fire at a time
17:57 <TemptorSent> mmlb: Okay... but I think you can PXE boot the image directly just fine.
17:57 <Klowner> mmlb: ooo, I think I may have gotten something
17:58 <TemptorSent> mmlb: I'll look at hacking up the init script to make it even easier, since I'm doing it anyway to autoinstall ZFS.
17:58 <mmlb> TemptorSent: which image can be pxe booted?
17:58 <TemptorSent> mmlb: Any of them given the appropriate bootloader config I suspect.
17:59 <Klowner> nope..
17:59 <TemptorSent> mmlb: What are you using currently?
17:59 <mmlb> TemptorSent: I'm confused right now, what am I using for what?
17:59 <TemptorSent> Klowner: Note: using the new mkimage, not the existing images)
17:59 gopar joined
18:00 <TemptorSent> mmlb: What bootloader are you using to pxe boot your images?
18:00 <mmlb> TemptorSent: ipxe'ing kernel and initrd
18:01 <TemptorSent> mmlb: Oh, that's even easier, no weirdness from some vendor.
18:01 <mmlb> yeah
18:02 <mmlb> I'm testing the update to 3.5.2 locally with qemu doing straight kernel, initrd (extracted out of release iso) but was hanging on ip=dhcp arg with an error about AF_PACKET(2,8)
18:03 <mmlb> decided to come here and check your progress before hacking up extracted files
18:03 <TemptorSent> mmlb: Hmm, not sure why the kernel isn't getting it done itself, but the initrd should be able to handle that? If not, it needs to :)
18:05 <TemptorSent> mmlb: Take a look at the /etc/mkinitfs/features.d and see if any of them include the required files as is, that's the next major project to getting this whole mess cleaned up.
18:05 <TemptorSent> mmlb: The default settings for the initrd don't include network fs stuff, so you'll be SOL if you need to nfs mount root or whatnot unless you roll your own.
18:05 <mmlb> TemptorSent: I attributed it to missing modloop so not having AF_PACKET modprobe'd
18:06 <TemptorSent> mmlb: Right. I've taught mkimage how to build modoops too, and have a TODO to include filtering of included modules there as well.
18:06 <mmlb> TemptorSent: nope no network fs stuff, just modloop, but if I can just have initrd with what I need then thats even better
18:06 <TemptorSent> er, modloops.
18:07 <TemptorSent> mmlb: Yeah, you can bake-in whatever you need in the initramfs and forego the modloop entirely in many cases.
18:07 <TemptorSent> I guess I should get on with pushing my changes to mkinitfs as it currently stands.
18:08 <mmlb> less pieces is better for me, if I could have initrd baked into kernel then that would just be grand :D
18:08 <TemptorSent> mmlb: That will take a bit more doing, since we'd have to build a kernel from scratch to include it directly, but it's not impossible.
18:08 <TemptorSent> I just haven't done more than stub the custom-kernel code yet.
18:09 <mmlb> yeah getting kernel initrd is great right now
18:16 <TemptorSent> mmlb: Anyway, it looks like if we can get it pulled together, this might hit mainline by 3.6. Much testing needed :)
18:18 <TemptorSent> mmlb: So if anything major needs to be reworked, I'd love to hear about it sooner than later.
18:20 <mmlb> TemptorSent: I'll be testing it for my use cases and will surely let you know
18:21 <TemptorSent> mmlb: Excellent. I expect a fair amount of breakage in untested sections, but nothing that should be too major to fix.
18:22 <TemptorSent> mmlb: I don't like the way I'm currenly doing a couple of things because they make things a bit hard to follow, but those are on my short list to rework.
18:23 <mmlb> TemptorSent: yeah i've done a little bit of jumping around but nothing seems horrible/insurmountable
18:24 <TemptorSent> mmlb: The overlays being overloaded being the primary one -- the deps will move to their own functions so we don't have multiple-calling issues.
18:24 <mmlb> ahh yeah, I'm skipping the overlays ;)
18:24 <TemptorSent> mmlb: And a general deps resolver would be good.
18:25 <mmlb> true, but I wouldn't want to make this wait on that seems sorely needed
18:25 sergey_ joined
18:26 <TemptorSent> mmlb: I have a (mostly untested) deps resolver for the overlays to help make sure they apply in the right order, but haven't messed with the rest yet.
18:27 <TemptorSent> mmlb: Basically, it doesn't break things currently with no deps in use, but it hasn't been tested against more than the simplest dep trees.
18:35 <mmlb> TemptorSent: --profile virt does not seem to build initramfs into iso
18:36 <TemptorSent> Hang on a sec, I may have not pushed a change.
18:37 <mmlb> TemptorSent: also looks like the device tree step adds a space to the working dir at the end
18:38 <TemptorSent> Well crap, I just ran out of space on my device.
18:38 <TemptorSent> This might take a while.
18:38 <mmlb> :D
18:40 <TemptorSent> mmlb: Okay, wiped the working directory, back in business.
18:40 <TemptorSent> mmlb: Attempting build of virt now.
18:40 <mmlb> kk
18:41 <TemptorSent> mmlb: Where did you see the space in the device tree step? I haven't tested that code path yet.
18:42 <mmlb> https://gist.github.com/mmlb/a24820c1cd69fe4614dad2cb5d64388f
18:42 <TemptorSent> mmlb: Never mind, found.
18:43 <mmlb> sorry I assumed it was in dt step, should have worded a bit better
18:44 <TemptorSent> mmlb: fix pushed, it was in device tree step, had a space in a mkdir command.
18:44 <mmlb> yup just pulled
18:45 <mmlb> TemptorSent: seeing symbolic link loop, normal?
18:45 <TemptorSent> mmlb: It's building for me for x86_64 it seems.
18:45 <TemptorSent> mmlb: Where's the link loop?
18:46 <mmlb> hmm let me see something
18:47 <mmlb> cp: can't stat './kernel_stage_devicetree-tmpworkker-843872e6e3445ddc88f2aa9fcff10614ad8d23f8.work/kernel_stage_devicetree-tmpworkker-843872e6e3445ddc88f2aa9fcff10614ad8d23f8.work/...... until it fails
18:48 <mmlb> TemptorSent: note I have `--work=/tmp/work` tried again after adding `/` to the end and no problems, went back to missing `/` and also worked
18:48 <TemptorSent> mmlb: Woah, that's odd. Must have missed a -p on a mkdir?
18:50 <mmlb> hmmm idk, I just blew the work dir away and tried it both ways and had no problems. Maybe something from before I pulled
18:50 volleyper joined
18:50 <mmlb> TemptorSent: now stat errors in `overlays-alpine`: cp: can't stat './.ovlroot/etc/runlevels/sysinit/devfs': No such file or directory
18:51 <mmlb> TemptorSent: see gist for new file with errors
18:52 <mmlb> I'll be back in about an hour
18:53 <TemptorSent> mmlb: Hmm, what FS is that on?
18:54 <mmlb> zfs
18:55 <mmlb> ohh
18:55 <mmlb> hmm I can move to xfs
18:55 <TemptorSent> mmlb: Okay - It looks like that's dying in the merge cp -lR may not be happy.
18:56 <mmlb> TemptorSent: I'll debug a bit better when I get back
18:56 <TemptorSent> mmlb: Yeah, it's the issue with hard links crossing filesystems I suspect...
18:56 <TemptorSent> mmlb: I'll have to go back to standard copy if we can't find a way around that.
19:02 c0ssacks joined
19:07 blueness joined
19:08 IRCFReAK joined
19:24 gopar joined
19:27 cyborg-one joined
19:54 gopar joined
19:56 <mmlb> TemptorSent: hmmm yeah $workdir and $outdir are 2 different fses
19:58 gopar joined
19:59 gopar joined
20:10 blueness joined
20:23 Ayyad joined
20:27 ahrs joined
20:29 ahrs joined
20:44 <TemptorSent> mmlb: Okay, that would explain why I wasn't seeing that issue pop up.
20:44 <mmlb> TemptorSent: still seeing it with /tmp/work and /tmp/out, or even with nothing at all
20:45 <mmlb> I'm running alpine in a docker container though so maybe something weird there too
20:45 <mmlb> let me try on a full alpine machine
20:46 <TemptorSent> mmlb: Okay, let me check something...
20:47 <mmlb> ok
20:47 <TemptorSent> mmlb: I think at least part of the issue is I left a stale . directory in the output directory and it's recursing that now that it's using cpio rather than cp :)
20:50 <TemptorSent> mmlb: I think I found it, a bit of legacy from the old build system is the DESTDIR gets moved, so I had dropped the root for the overlays in the destdir/.ovlroot.
20:50 <TemptorSent> mmlb: Let me move that and see if it fixes things, one min.
20:52 IRCFReAK joined
20:52 <mmlb> TemptorSent: sgtm thanks
20:53 <TemptorSent> mmlb: Pull that and let me know if the problem goes away :)
20:54 <TemptorSent> mmlb: hang on, I tripped something else with that possibly, let me rebuild virt and see.
20:54 IRCFReAK joined
20:55 <TemptorSent> mmlb: Not there, back in device tree.. odd.
20:59 IRCFReAK joined
20:59 <TemptorSent> mmlb: That was the first time I saw the symlink loop pop up...
21:02 <TemptorSent> mmlb: It looks like it was a stale link caused by the previously fubar mkdir, acting fine after cleaning up work dir.
21:02 <* IRCFReAK> i beliv i can fly
21:02 <TemptorSent> mmlb: Give that a shot and let me know if it fixed the issue for you.
21:03 <mmlb> hmm yeah I may have done ^C at some point
21:03 <mmlb> will try
21:04 <TemptorSent> mmlb: Thanks - it's hard to debug when you're stuck with one (semi) working box in front of you and not much else to test on off hand.
21:05 givemeparttt2000 joined
21:05 <TemptorSent> mmlb: And a couple tin cans with a string between them for a network doesn't help either :)
21:05 KSD joined
21:05 <KSD> Hello everyone !
21:05 preyalone joined
21:06 <TemptorSent> Hello KSD.
21:06 <mmlb> TemptorSent: ohhh that looks much better
21:06 <mmlb> oh wait
21:06 <mmlb> TemptorSent: Illegal option -P \n usage: mkinitfs
21:06 <TemptorSent> mmlb: Relying on . dirs not globbing didn't help.
21:07 <KSD> I want to contribute to Alpine, do you know you I've to contact ?
21:07 <TemptorSent> mmlb: *lol* That's right, I'm using the git head of mkinitfs too....
21:07 <mmlb> :D
21:08 <mmlb> how should I get?
21:08 <TemptorSent> mmlb: Since I'm not *YET* forcing my own features, I can just disable that opt for now.
21:08 <mmlb> ok
21:09 <TemptorSent> mmlb: But there may be other breakages in the stock version, so I'd suggest pulling it anyway... git clone git://git.alpinelinux.org/mkinitfs
21:10 <mmlb> TemptorSent: I assume remove -P and /etc/mkinitfs/features.d
21:10 <mmlb> TemptorSent: ok thats fine I'll get git head
21:10 <TemptorSent> mmlb: Yes, that should make it at least try with the old mkinitfs.
21:11 <TemptorSent> mmlb: you may need to pull the fixed lddtree too, although I think that made it to the repo, so just make sure it's updated...
21:11 givemeparttt2000 joined
21:11 <TemptorSent> mmlb: 1.26 or better should be okay.
21:12 <TemptorSent> mmlb: I started turning up all sorts of fun bugs when I started doing the cross-arch builds.
21:14 <TemptorSent> KSD: Many of the devs hang out here during the weekdays (CETish TZ), so dropping in about 4 hours earlier on Monday would be a good bet I suspect.
21:14 <TemptorSent> KSD: What were you planning to work on?
21:15 <KSD> French translation
21:15 <TemptorSent> mmlb: Yeah, mkinitfs is going to get canabalized into mkimage (mkalpine?) sooner than later.
21:16 <TemptorSent> KSD: Unfortunately, I'm not particularly familiar with the i18n/l10n efforts on Alpine, so I'll have to punt you to someone else there.
21:16 givemeparttt2000 joined
21:18 <TemptorSent> KSD: Generally it's just a matter of building translation files for the strings marked for i18n.
21:19 <TemptorSent> KSD: But alpine handles the installation of translations a bit differently.
21:20 <KSD> TemptorSent: Do you know if I can help or not ?
21:21 <TemptorSent> KSD: I'm sure any contributions would be welcome, but I'm not sure how much help is available to get you up to speed on the process.
21:23 <tmh1999> KSD : Contribution are always welcome. First step I think you should go through Alpine wiki page, especially those for developers, to see if any part related to translation
21:23 <tmh1999> KSD: and yeah stick around CET timezone :)
21:24 <KSD> TemptorSent: I'll propose my help monday morning when devs will be awake ;)
21:24 <tmh1999> KSD : So you want to translate the website or ?
21:25 <TemptorSent> tmh1999: With a caveat that much of the website is horribly out of date in terms of developer docs ;)
21:26 <KSD> tmh1999: yes whatever, I just want to help because in France more and more DevOps teams use Alpine
21:26 <KSD> Sorrymy english is frightful
21:27 <tmh1999> TemptorSent : Hard truth, hope someone will have time to fix it after 3.6
21:27 <TemptorSent> KSD: It's much better than my french!
21:27 <tmh1999> TemptorSent : That's the attitude !
21:28 <TemptorSent> tmh1999: Yeah, it would be good to sync everything to a milestone and at least note anything that's out of date.
21:28 <tmh1999> TemptorSent : I am picking up on reading abuild/apk-tools source to gain more understanding about them so I could help the docs
21:29 <tmh1999> KSD : That's great lots of people are using Alpine
21:29 <tmh1999> TemptorSent : Looks like you have some progress on aarch64. Beautiful
21:29 lamer14897856317 joined
21:29 <TemptorSent> tmh1999: Yeah, most of apk is undocumented :)
21:31 <TemptorSent> tmh1999: Yeah, aarch64 should be ready for fiddling with now -- once the various code-paths get some excercise, we can stick a fork in t.
21:31 <KSD> tmh1999: I agree but not enought unfortunatly
21:32 <tmh1999> TemptorSent: you changes in your github repo ?
21:32 <tmh1999> KSD: How so ?
21:32 <TemptorSent> tmh1999: Yeah, my github is current to my working system at the moment.
21:33 <KSD> tmh1999: Some teams are effraid by english language
21:35 <TemptorSent> KSD: For better or worse, english has become the lingua franca (how's that for irony) of computing. Translating the documentation and user interface is relatively doable, but the guts tend to be a bit more difficult.
21:35 IRCFrEAK joined
21:36 mmlb joined
21:37 <TemptorSent> KSD: Although I learned enough german to read docs back in the 80s.
21:37 <tmh1999> TempTorSent: You have docs in 80s ? You da real MVP
21:37 mmlb joined
21:37 <KSD> German... ouch...
21:38 mmlb joined
21:38 <TemptorSent> KSD: Yeah, it was painful -- especially computing terms, which often took full line for one word!
21:39 <KSD> Time to sleep, I'll re-ask monday morning when devs are awake. Goodnight, bye
21:39 <TemptorSent> tmh1999: Yeah, much of the Atari community was german at the time.
21:39 <TemptorSent> KSD: Goodnight, and see you then.
21:40 <tmh1999> TempTorSent: by the way, if you have some time, can I ask you about the travis you use in github ? I thought you are writing code for aarch64, thought Travis does x86 code ?
21:40 <TemptorSent> tmh1999; I haven't actually set up anything for travis yet.
21:41 <tmh1999> hum interesting
21:41 <TemptorSent> tmh1999: I'm cross-building the images on my local system using already-compiled packages, not building apks from source currently.
21:42 chapui_s joined
21:42 <TemptorSent> tmh1999: Other than me fubaring some arch-specific stuff (device tree, some boot file locations), it should "just work" for any arch you care to set up.
21:43 <TemptorSent> tmh1999: It only knows about grub2, syslinux/extlinux/isolinux, uboot, and rpi bootloaders currently, but more can be added easily.
21:44 <tmh1999> TemptorSent : That's amazing work you are doing
21:45 <TemptorSent> tmh1999: Once I get the core solid, I'll see about getting it to boot aarch64 images using qemu and setting up the aarch64 abuild env there.
21:45 <tmh1999> TemptorSent: Instead of me asking more dumb questions to you, do you happen to know some practical book/write-up/tutorial/blog that describe how to make the boot process ? initramfs, kernel, matching device at boot, etc. ?
21:46 <TemptorSent> tmh1999: Thanks. I hope is becomes a useful tool to the community at large.
21:46 <tmh1999> TemptorSent: it's more than useful my friend
21:48 <TemptorSent> tmh1999: Nope, no good docs I can think of -- a lot of wasted time, trial and error, and UTSL. I've been doing this stuff since the 90s, so I have to forget half (or more) of what I knew anyway.
21:50 <tmh1999> TemptorSent : that's tough. hum...
21:50 <TemptorSent> tmh1999: I can give you the basic outline if you want -- BIOS discovers the boot media and loads the bootloader (not so simple of a process actually), the bootloader loads the kernel image and initrd, sets the base, and boots it, passing on the kernel cmdline options.
21:51 <TemptorSent> The kernel starts up, then mounts the initramfs as /, then transfers control to init on the initramfs (see /usr/share/mkinitfs/initramfs-init).
21:53 <TemptorSent> initramfs-init does the work of loading the necessary modules to mount the root fs, in the case of alpine extracts the run-to-ram system, mounts /dev /proc /sys etc.., and does a switch-root and exec /sbin/init
21:54 <TemptorSent> /sbin/init is a link to busybox on alpine, which uses a simplified /etc/inittab to call openrc $softlevel for each of the runlevels automatically started.
21:55 <TemptorSent> Modloop is actually not mounted until the system is booted and in the sysinit soft-runlevel.
21:56 <TemptorSent> So all modules you need to mount the root fs need to be included in the initramfs.
21:56 minimalism joined
21:57 <TemptorSent> tmh1999: That's the outline, let me know what blanks you need filled in :)
21:58 <tmh1999> TemptorSent : I am trying to consume what you said.
21:58 <tmh1999> TemptorSent : Took note. Thanks for sharing !
21:59 <TemptorSent> tmh1999: No problem.
22:00 <TemptorSent> tmh1999: The process is a bit simpler in some cases where no bootloader is required, but I outlined the general case.
22:02 <tmh1999> TemptorSent : So if I have a disk device, it should be known by the initrd, so that initrd will mount it on the root fs ?
22:03 <TemptorSent> tmh1999: Yes, you'll need either baked-in kernel support or modules in the initramfs, since the modloop isn't available at that point yet.
22:04 <TemptorSent> tmh1999: I've contemplated ways of making the modloop work in the init environment, but it requires being a bit createive :)
22:06 <tmh1999> :)
22:06 <tmh1999> doing this line of work is already being creative
22:09 <tmh1999> TemptorSent : I mean, besides being supported by the kernel, or supported in the initramfs, the initrd needs to know some kind of address to that device ? Doesn't it ?
22:09 <tmh1999> TemptorSent : and initramfs and initrd (init ramdisk) are different thing ?
22:11 <TemptorSent> tmh1999: The initrd is actualy the old implementation which used a fixed ramdisk block device. The current initramfs uses a much simpler and cleaner ram-based filesystem.
22:12 <TemptorSent> tmh1999: The initramfs has both the drivers (modules) and detection logic in it, and the kernel parameters passed to it can tell it where to look (root=/dev/sdc2 say)
22:13 <TemptorSent> tmh1999: I haven't delved into the nlplug-findfs source yet, but that's what does the detection on alpine.
22:22 IRCFrEAK joined
22:25 IRCFrEAK joined
22:33 IRCFrEAK joined
22:42 IRCFrEAK joined
22:43 fekepp joined
22:44 IRCFrEAK joined
22:44 IRCFrEAK left
22:44 IRCFrEAK joined
22:45 IRCFrEAK joined
22:47 IRCFrEAK joined
22:48 IRCFrEAK joined
22:52 IRCFrEAK joined
22:53 IRCFrEAK joined
22:56 IRCFrEAK joined
22:57 IRCFrEAK joined
23:05 IRCFrEAK joined
23:05 lamer14897914062 joined
23:07 IRCFrEAK joined
23:10 kvda joined
23:12 IRCFrEAK joined
23:15 <mmlb> TemptorSent: thanks for all the help today, I've got to run now. I shall get back on this next week!
23:15 <mmlb> have a good weekend
23:22 IRCFrEAK joined
23:28 damongant joined
23:42 alacerda joined
23:46 blueness joined
23:47 ogres joined
23:54 Nobabs27 joined
23:56 <Nobabs27> I have a kind of a complicated question about permissions: say I wanted to allow 1 user to add packages and users, and delete any user except "babs", and not have let change IPTables
23:56 <Nobabs27> *not let them change IPTables
23:59 <Nobabs27> ok well I think I just figured part of that out, but I still need to figure out how not allow them to remove my user...