<    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:17 sparklyballs joined
00:33 dirac1 joined
00:40 snaphuman joined
00:47 blueness joined
01:19 royger joined
01:29 blueness joined
01:30 bozonius joined
01:45 laj joined
02:08 mdillon joined
02:17 <ldleworker> Xe: https://gist.github.com/dustinlacewell/9440e101e7d668d1b1d407019a234cf3
02:18 <Xe> ldleworker: docker run --rm -it alpine:3.5 sh
02:18 <Xe> then # apk update
02:19 <ldleworker> Xe https://gist.github.com/dustinlacewell/a2920035ac3c7b41b420f2b27b5a83d1
02:19 <Xe> ldleworker: nslookup dl-cdn.alpinelinux.org
02:20 <Xe> if that fails, reboot your docker build host
02:21 <ldleworker> Xe: well it fails from inside the container you told me to run
02:21 <ldleworker> but not from my host
02:21 <Xe> yeah
02:21 <scv> r e b o o t
02:21 <Xe> reboot your host
02:21 <Xe> something's fucky with dns
02:21 <ldleworker> OK I will, but why?
02:21 <ldleworker> OK
02:21 <scv> rebooting is never the fix
02:21 <Xe> scv: no, but it hides the problem
02:22 <scv> this isn't windows
02:22 <ldleworker> Well should I reboot or not? lol
02:22 <Xe> ldleworker: reboot or at the least restart docker daemon
02:22 dirac2 joined
02:23 <ldleworker> restarting docker daemon worked
02:23 <ldleworker> thanks
02:23 <Xe> np
02:23 <ldleworker> Xe, I'm working on a docker-backed package manager :)
02:24 <Xe> ldleworker: seems reasonable
02:24 <Xe> good choice of distro
02:24 <ldleworker> Well, alpine is just used for the images.
02:24 <ldleworker> Not the host OS
02:24 <ldleworker> dckr-get install weechat
02:24 <Xe> yeah
02:24 <Xe> that's what i meant
02:24 <ldleworker> will install the image, and give you a `weechat` alias that runs the container
02:24 <ldleworker> Ah OK :)
02:24 <Xe> look at subuser
02:25 <ldleworker> Doh.
02:25 bluetazmanian joined
02:25 <ldleworker> :P
02:26 <ldleworker> Xe is this exactly what I imagined?
02:26 <ldleworker> Or just something similar.
02:26 <Xe> ldleworker: i can't read your mind, but probably
02:27 <ldleworker> hehe
02:27 <ldleworker> I recently switched from a monospace sans font, to a nice serif font on IRC
02:27 <ldleworker> I can't believe how much nicer IRC is now.
02:27 s33se_ joined
02:38 coin3d joined
02:49 snaphuman joined
03:17 Nobabs27 joined
03:24 blueness joined
03:37 cyteen joined
03:48 cyteen joined
03:53 mdillon joined
03:56 vectr0n joined
04:03 sparklyballs joined
04:04 mguentner joined
04:09 mguentner joined
04:47 __machine joined
04:49 <__machine> are new versions of docker generally backported into the stable release? reason being docker 1.13 supports automatic api version negotiation (so 1.13 client can talk to 1.12 server)… i am deploying alpine containers to docker cloud and i don't really have control over which server version is running so i can't reliable force it by setting `DOCKER_API_VERSION` in my alpine container
05:12 Guest68436 joined
05:21 blueness joined
06:02 gopar joined
06:02 cyteen joined
06:08 Ayyad joined
06:21 fabled_ joined
06:22 <__number5__> __machine: apline is rolling updates model, no needs to backport. yes docker-engine update quite often
06:24 <__number5__> __machine: btw, if you just running alpine as container (not as docker host), you don't need to care about the docker version *inside* alpine container
06:25 <avih> __number5__: only edge is rolling. stable releases are not (e.g. 3.5[.x])
06:30 <__machine> __number5__: i want to use a stable release (this is production) but the version of docker client on alpine 3.5 is 12.6 and that will only work with docker server of same api version… docker server version is controlled by docker cloud (not me) and it changes from time to time… i am running alpine as a container, but i mount the docker socket from the host into the container so i can exec commands in other containers on the same
06:31 <__machine> i read on the wiki that packages are backported into stable release sometimes if you ask on irc/forum/etc and have a good reason
06:32 ldleworker left
06:39 <__number5__> __machine: you can add edge repo to you stable apline, allowing only docker-engine use edge version, check the apk page on wiki
06:40 <__machine> does that generally work fine?
06:40 <__number5__> avih: yep, you are right. I'm thinking security updates...
06:41 <__number5__> __machine: it should be fine unless docker changed hugely required some libs version not in stable alpine (which is rare)
06:41 <avih> __machine: generally yes, but not always. on some cases edge breaks (and then quickly unbreaks, but still)
06:43 <__machine> so it would have to be an extreme defect to consider backporting a package into stable, so that it too remains stable?
06:44 <avih> stable in general gets security updates. i'm guessing major bugs could too, though not sure.
06:45 <avih> as for pinning, i _think_ you can pin a specific version of docker from edge. so as long as you verify this version works for you, you can manually upgrade just the docker version to some specific $version from edge
06:45 wonton__ joined
06:47 <__machine> thanks, i'll try that
06:47 xsteadfastx joined
06:48 wonton___ joined
06:54 wonton joined
06:56 sparklyballs2 joined
06:57 <avih> __machine: though thinking about it, not sure how that'd work. since packages at the repos are latest for a specific alpine version AFAIK, so if docker updated on edge, it doesn't sound reasonable that older versions will be kept around (much?).
06:57 <__machine> doh
06:58 <avih> but i'm out of my depth. maybe wait for someone more knowledgeable to reply.
07:12 gogoprog joined
07:25 nanohest joined
07:41 blueness joined
07:45 avih joined
07:51 wonton_ joined
08:09 stwa joined
08:13 Ayyad joined
08:19 cyborg-one joined
08:21 cyteen joined
08:22 bluetazmanian joined
08:27 sergey joined
08:32 __machine joined
08:53 ProXy left
08:54 bluetazmanian joined
08:54 bluetazm_ joined
09:06 nanohest joined
09:08 t0mmy joined
09:16 ptman[m] joined
09:16 <ptman[m]> I get python segfaults on alpine, is that common?
09:17 fekepp joined
09:23 bluetazmanian joined
09:48 bluetazmanian joined
09:52 discensa joined
09:52 nanohest joined
09:56 urzds joined
09:57 nanohest joined
09:59 stwa joined
10:05 roedie joined
10:06 <roedie> Hi, does anyone know if there is any effort on getting OpenStack running on Alpine?
10:41 bluetazmanian joined
10:42 bluetazm_ joined
11:02 bluetazmanian joined
11:11 bluetazmanian joined
11:51 gromero joined
11:56 czart_ joined
12:04 sparklyballs joined
12:10 blueness joined
12:18 blueness joined
12:21 blueness joined
12:26 bluetazmanian joined
12:34 blueness joined
12:42 bluetazmanian joined
12:44 blueness joined
13:16 bluetazmanian joined
13:25 bluetazmanian joined
13:29 farosas_ joined
13:37 bluetazmanian joined
13:51 Skele joined
13:56 hairyhenderson joined
14:07 ^ingo^^^ joined
14:24 mdillon joined
14:28 sparklyballs joined
14:36 bluetazmanian joined
14:36 sparklyballs joined
14:56 <Xe> ptman[m]: can you give more detail?
15:02 stwa joined
15:03 mmlb joined
15:09 Emperor_Earth joined
15:22 bluetazmanian joined
15:22 teleno joined
15:22 teleno left
15:23 <ptman[m]> Xe: so that bug report actually gives more detail than I can dig up
15:24 <ptman[m]> I just got python[17245]: segfault at 7f1f0cf278a8 ip 00007f1f05a5db6c sp 00007f1f0cf278a0 error 6 in ujson.so[7f1f05a57000+209000]
15:24 cyborg-one joined
15:34 sparklyballs joined
15:38 fabled joined
15:38 bluetazmanian joined
15:38 rollniak joined
15:41 igitoor_ joined
15:46 igitoor_ joined
15:49 bluetazm_ joined
15:53 <odc> ptman[m]: thanks for opening the issue on github ;)
16:05 bluetazmanian joined
16:11 <TBB> okay; on laptops I have no problems with Alpine, but on desktop PCs I still run into this annoyance that is keyboard and mouse not working on lxdm startup, I need to re-plug the mouse in and it seems to generate a device scan event of some sort after which peripherals work
16:11 <TBB> what am I missing here?
16:14 bluetazm_ joined
16:28 <fabled> TBB, on udev? maybe udev-trigger is not activated service?
16:28 <fabled> i think setup-xorg-base is missing that
16:28 <fabled> but setup-udev does it properly
16:29 <fabled> ncopa, ^ was setup-xorg-base ever fixed to call setup-udev?
16:32 <TBB> admittedly, since I work in a restricted environment, my current install repositories are a snapshot of 3.4.6 so it might have been fixed since
16:33 <TBB> but knowing what you just told me will probably help me enough to fix the setups here. let me dash to the Other Side to check this.
16:37 meena joined
16:42 <TBB> yup, that's the fix. thank you once again fabled :)
16:48 bluetazmanian joined
16:50 bluetazmanian joined
16:50 bluetazmanian joined
16:51 bluetazmanian joined
16:53 Ayyad joined
16:53 bluetazmanian joined
16:58 bluetazmanian joined
16:59 dlaube joined
17:01 meena joined
17:16 bluetazmanian joined
17:16 mikeee_ joined
17:18 Ayyad joined
17:24 Shiz joined
17:27 <ptman[m]> odc: let's hope it helps, I have no idea
17:32 bluetazmanian joined
17:37 ptman[m] left
17:48 n3u3w3lt joined
17:48 gopar joined
17:50 bozonius joined
17:54 <gopar> Anyone using alpine + vagrant? For some reason after updating apk, exiting shell and re-logging(vagrant ssh) in again it hangs up. Always freezes. Not sure why
18:11 bluetazmanian joined
18:22 nanohest joined
18:32 bluetazmanian joined
18:35 alacerda_ joined
18:37 Berra joined
18:39 bluetazmanian joined
18:45 orbiter joined
18:53 bluetazmanian joined
19:03 coin3d joined
19:09 cyborg-one joined
19:23 bluetazmanian joined
19:30 bluetazmanian joined
19:33 minimalism joined
19:53 bluetazmanian joined
19:57 <ncopa> fabled, TBB no i dont think we ever fixed setup-xorg-base
19:58 sparklyballs joined
20:02 bluetazmanian joined
20:07 blueness joined
20:09 bluetazmanian joined
20:12 sparklyballs joined
20:14 LouisA joined
20:24 nanohest joined
20:28 fireglow joined
20:35 gopar joined
20:36 bluetazmanian joined
20:37 gopar joined
20:44 alacerda__ joined
20:49 bluetazmanian joined
20:54 rollniak joined
20:56 bluetazmanian joined
21:17 Latrina joined
21:23 alacerda_ joined
21:27 bluetazmanian joined
21:40 fekepp joined
22:07 kaaaat joined
22:07 Berra joined
22:09 <Xe> how do you make alpine boot from EFI?
22:10 <TBB> simple
22:10 miggyb joined
22:11 <TBB> add gummiboot to your install, copy its efi binary to /boot/EFI/boot/bootx64.efi and write the configuration files /boot/loader/loader.conf and /boot/loader/entries/yourentry.conf
22:11 <Xe> better question
22:11 <Xe> why isn't that already done for existing boot media?
22:12 <Xe> i have a small cluster of atoms that only boot over EFI
22:12 <TBB> just a guess, but UEFI systems can usually boot with "legacy" settings but legacy systems can't boot UEFI
22:13 <Xe> TBB: these minnowboards cannot
22:13 <TBB> also, those two usually use different bootloaders... I don't even know if syslinux properly supports UEFI still; I went with gummiboot
22:22 cyteen joined
22:29 <TemptorSent> Xe: There appears to be a grub-efi package that is also supported under isolinux's hybrid mode as in addition to gummiboot.
22:29 doppler left
22:31 <TemptorSent> Xe: Either way, if you'd be willing to help alpha test the new mkimage code, it should be able to spit out custom images with whatever bootloader you want after only minor modification.
22:31 <Xe> (Y)
22:32 <Fearfulx> ia32-libs where do I find this?
22:32 <Fearfulx> it's needed for sa mp
22:35 ogres joined
22:36 <Fearfulx> let me guess it's not supported?
22:36 <Fearfulx> amazing...
22:37 bluetazmanian joined
22:39 bluetazmanian joined
22:40 <Fearfulx> guess there is no work around
22:40 <Fearfulx> i don't care to reinstall right now to another os
22:40 <Fearfulx> =/
22:40 <scv> Fearfulx you could copy the i386 libs from another install
22:40 <scv> i've had to do it for some binary-only apps
22:40 <scv> works fine
22:40 <scv> even if it's glib
22:40 <scv> glibc
22:41 <scv> its a little hacky but it does work
22:41 <Fearfulx> how would I do it?
22:41 <Fearfulx> meh
22:41 <Fearfulx> got a guide?
22:42 <scv> i dont know of any guide
22:42 <scv> you can use the ldd tool to find out what libraries the binary needs
22:44 <Fearfulx> 22:43:07 fear@doomsday:~/samp03$ ldd /home/fear/samp03/samp03svr
22:44 <Fearfulx> ldd: /home/fear/samp03/samp03svr: Not a valid dynamic program
22:46 <Fearfulx> meh I suppose I don't need alpine linux... maybe a year they will add this crap
22:47 blueness joined
22:49 bluetazmanian joined
22:49 <Fearfulx> gentoo hardened will be good enough
22:49 <Fearfulx> until they can add 32bit lib support and shit
22:52 Ayyad joined
22:53 fireglow joined
22:55 vidr joined
23:01 <TemptorSent> Fearfulx: If you need to support a bunch of 32bit crap, consider just setting it up in it's own root with funtoo and keeping it away from the rest of the system.
23:01 bluetazmanian joined
23:02 <TemptorSent> Fearfulx: Install a stage-3 in /x86_32 or something and setup the chroot for that.
23:03 <TemptorSent> Fearfulx: You could even try doing a "prefix" install, where funtoo actually lives peacefully with no chroot and just sits under the directory you specify.
23:04 <Fearfulx> i'll do it my way.. I thought alpine linux would at least have minimum support forsomethign this simple
23:04 <Fearfulx> guess not
23:06 <TemptorSent> Fearfulx: The issue with supporting parallel 32 bit libs is a significant increase in size because of the duplication, not to mention many libs getting cranky about which version they find.
23:07 <Fearfulx> yet debian minimal has no issue
23:07 <TemptorSent> Fearfulx: My main distro is funtoo for more general work for that reason.
23:07 <TemptorSent> Fearfulx: What's the minimal installed size of debian-minimal?
23:07 <Fearfulx> about 200mb
23:08 <TemptorSent> I'm working on a new image builder for alpine and I'm already at less than half that for a bootable install.
23:09 <TemptorSent> Fearfulx : Aiming for < 40mb bootable for virt if I can, and < 20 for containers.
23:09 <TemptorSent> Fearfulx : So almost an order of magnituded difference in size for the "minimal" configurations.
23:10 <TemptorSent> Heck, I think the funtoo stage-3 is less than a couple hundred megs, and that's a full dev setup.
23:12 <TBB> you can always make images smaller, but just how functional they are and how usable the image is is another question...
23:12 <TBB> you don't get to just drop stuff off and have things work nevertheless
23:12 bluetazmanian joined
23:13 <TemptorSent> TBB: The point of the minimal image is to bootstrap itself, then stack what you want on top of it.
23:13 <TBB> yup, that's stuff I've spent the last 4 years of my career on
23:13 <TemptorSent> TBB: I'm pretty sure I can dump 99% of the scsi stack out of the current images with impunity!
23:14 <TBB> I guess it all comes down two what we're talking when talking about images and what the usage for those images is, really
23:14 <TemptorSent> Right now, I'm trimming down the base images to what they need and nothing else.
23:14 <TBB> for example, "apk add alpine-base" is -the- minimal Alpine setup
23:15 <TemptorSent> TBB: Actually, no it's not :)
23:15 <TBB> it's good for chroots and stuff, and serves as a base for more complicated setup
23:15 <TBB> it is at least in one way
23:15 <TBB> that's what the minimal setup defined by the distribution seems to be
23:15 <TemptorSent> apk add alpine-baselayout alpine-keys apk-tools busybox libc-utils
23:16 <TemptorSent> Look at the minirootfs.
23:16 <TBB> and also there's the question of practicality
23:16 <TemptorSent> That's perfect for setting up chroots.
23:16 bluetazmanian joined
23:16 <TemptorSent> You don't want nor need anythign else.
23:16 <TBB> you can't be sure that minimal setup works when something changes
23:17 <TemptorSent> ??
23:17 <TBB> alpine-base on the other hand has upstream's guarantee
23:17 mguentner joined
23:17 <TemptorSent> alpine-base include quite a bit of other stuff that you DONT wan't in a chroot.
23:17 <TBB> see, while I'm obviously attached to the whole topic and see the point of having minimal size images,
23:17 <scv> Fearfulx: it's not a missing feature, it's intentional
23:17 <TemptorSent> Such as openrc
23:18 <scv> Fearfulx: 32 bit compat on a 64 bit distro is a very legacy option and is rarely necessary
23:18 <TBB> there's a line after you've crossed it your optimisation becomes more a waste of time than useful work
23:18 <TBB> (and "your" in this context doesn't refer to YOU specifically)
23:19 <TemptorSent> TBB: Hmm, how many chroots reduced by a 20mb a piece does it take to add up to real ram?
23:19 <scv> Fearfulx: if it's something you need for sa:mp then maybe you should use a different distro for that, alpine is probably not the ideal choice to run a binary-only application
23:20 <Fearfulx> welp, onlyuse alpine linux is for me is on a server
23:20 <TemptorSent> TBB: If you're trying to run from ram, it's rather useful to have minimal image size.
23:20 <Fearfulx> since it won't offer anything worth a crap to me
23:20 <Fearfulx> then i guess I'll get rid of it
23:20 <Fearfulx> disappointing
23:20 <Fearfulx> had so much potential
23:20 <Fearfulx> anyway
23:20 <TBB> and there's another thing. how much a dev gets paid doing optimization like that vs how cheap RAM is ... I know, that even goes against what I believe in, I like getting things done properly but there's a limit to how much money the wallet of the payer has
23:20 <TemptorSent> Fearfulx: It's all about choosing the right tool for the job at hand.
23:21 <scv> exactly what TemptorSent said
23:21 <TBB> seconded; Alpine is good for some use cases, bad for some others; same goes for virtually every distro
23:21 <TemptorSent> TBB: There's that, but then again, there's me wasting that much less time fighting my own systems.
23:22 <scv> alpine's goal is to be lightweight, if you're looking for 32 bit compat in a 64 bit distro, you're essentially duplicating the entire system and doubling its size
23:22 <scv> that's not lightweight
23:22 <scv> if you're trying to run a 32 bit app, use the 32 bit version
23:22 <scv> not the 64 bit
23:22 <TemptorSent> Fearfulx : For what you need, I would highly recommend lookign at funtoo -- you can build the system to support exactly what you need, and stil cut out the extra crap.
23:22 gopar joined
23:22 <scv> or again TemptorSent's right, funtoo would likely be a good fit
23:23 gopar joined
23:23 <TemptorSent> Funtoo will only build the packages that are required, and they will be 32 bit versions of the SAME packages as the 64 bit versions, so at least you have a better chance of thigns playing nicely when they include the header from one and use the library from the other.
23:25 <TemptorSent> Fearfulx : Alpine more intended for single-purpose, embedded, or minimally configured applications, not so much general workstation/desktop use (although it supports that quite well within some limitations)
23:26 <TemptorSent> TBB: So a question for you, regarding the "base" configuration -- what packages should it include in the rootfs?
23:26 <TemptorSent> TBB: Do we really need everything in network-extras, or should we cherry-pick, then let the other profiles include as needed?
23:27 <Fearfulx> no use to be here anymore meh
23:27 Fearfulx left
23:27 <TemptorSent> TBB: For instance, a rpi probably doesn't need bridging, vlan, and ppp support by default.
23:27 <scv> man
23:28 <scv> he reeks of troll
23:28 <TemptorSent> Wow, that was interesting...
23:28 <scv> "why don't you guys include two copies of every library"
23:28 <scv> >lightweight distro
23:28 <TemptorSent> scv: It wouldn't be impossible to support a nested configuration, but it would take a fair bit of effort to make everything play nice
23:29 <scv> of course it's not impossible, but it flies directly in the face of alpine's intended goals/use case
23:30 <TemptorSent> scv: Not necessarily, as long as it was essentially alpine-on-alpine.
23:30 <TemptorSent> scv: I actually need that sort of nesting support in some cases myself, but not quite the same way.
23:30 <TBB> I also make my own image maker
23:30 <scv> i'd just say use a chroot if you absolutely need to run a proprietary 32 bit app on a 64 bit install
23:30 <TemptorSent> VMs on a iso image to be net-booted to ram.
23:31 <scv> but this guy reeks of troll
23:31 <scv> 23:07 < Fearfulx> yet debian minimal has no issue
23:31 <scv> if debian minimal has no issue then why don't you just go use debian minimal then :^)
23:31 <TBB> I understand where he's coming from in a way but his communication could be a bit less negative
23:31 <TemptorSent> scv: That's what I was suggesting, supporting a nested chroot somewhat intelligently.
23:31 <TemptorSent> TBB: Agreed. I was young and angry once...
23:32 <TemptorSent> TBB: ...not quite so young any more :)
23:32 <scv> just sounds like he wants his application to just work out of the box, no effort required
23:32 <TBB> TemptorSent: that is a good question; I guess my own needs are more focused on desktops and laptops, but minimalistic environments naturally benefit from proper optimization
23:32 <TemptorSent> scv: It would always be nice.
23:33 <TBB> yeah, I would probably be much father along with my work effort had I not chosen Alpine as the base distro
23:33 <scv> TemptorSent: again, right tool for the job
23:33 <TBB> however
23:33 <TemptorSent> TBB: The profile builder will allow you to setup anythign from a skeleton rootfs to a fully configured server with services running and data loaded.
23:34 <TBB> I don't mind, because using Alpine pushes me forward in my own knowledge of Linux distributions, packaging, all kinds of things
23:34 <scv> i like alpine because the system is small enough to the point where i can understand every component that's present, it's not a massive pile of interdependent packages that are all tweaked and managed in a distro-specific way (i.e. debian, fedora etc)
23:34 <TBB> and Alpine has some of the security already implemented that I would've had to implement myself using just about any other distribution
23:34 <TemptorSent> TBB: Yeah, I'm almost two weeks behind on a deliverable because I got sucked into fixing alpine's old build system (the one one the wiki) before finding out it was depreciated, and now essentially rewriting mkimage into a general-purpose image builder, not just a releae tool.
23:34 <scv> to me feels like a lot of the linux ecosystem is drifting towards excessive complexity
23:34 <TBB> okay, so it requires me to do some magic with packaging sometimes, but that's what I get paid for
23:35 <TBB> TemptorSent: makes me wonder... if I ever get to publish my own installer (I do have a preliminary license to do that but it's still stuck in bureaucracy)
23:36 <TBB> ... there might be some synergy between what you do and what I do
23:36 <TemptorSent> scv; I remember when I was loading *floppies* into a 386 to install slack... I think it was less than 5 for the whole system, the rest were optional!
23:36 <TBB> because based on what I've been reading on this channel from you lately (while too busy to engage in a conversation) I believe there might be synergies achievable
23:37 <TemptorSent> TBB: I made a stupidly simple plugin loading system that does most of the work now..
23:37 <scv> TemptorSent: the good old days :)
23:37 <TemptorSent> scv : It sure beat typing minix in off harcopies!
23:37 <TBB> heh, mine is pure Bash (got an sh implementation as well but I really like associative arrays)
23:37 <scv> TemptorSent: and now we have the monstrosity known as systemd, an era where /sbin/init uses more memory than was physically present in some machines i used to use
23:38 <TemptorSent> TBB, yeah - it took me a while to get over my bashims (mostly -- I use ${var//s/r} since we happen to support it and it saves a lot of pain in a few places.
23:39 <TBB> it's natural that the Linux ecosystem is bloated, but like Alpine for example demonstrates, you can still keep things small, simple and effective
23:40 <TemptorSent> TBB: Yeah, but you have to work for it these days!
23:40 <TBB> TemptorSent, I wrote the sh implementation to figure out how much cleaner I could pull off all the features I wanted, but I quite soon came to the conclusion Bash and bashisms are not that bad
23:40 <TBB> true, someone needs to keep things under control
23:41 <TBB> btw, I spent some time with early Linux and was like "who the hell is going to ever use this?"
23:41 <TBB> and happily spent 3-4 years using FreeBSD
23:41 <TemptorSent> TBB: Have you had a chance to take a look at my mkinitfs branch? https://github.com/TemptorSent/aports/tree/mkimage-refactor-scripts/scripts/mkimage
23:42 <scv> yeah, freebsd was my first personal *nix as well
23:42 <TBB> TemptorSent: no I haven't. I could have a look tho if I can squeeze a couple hours into this weekend for it :)
23:43 <TemptorSent> TBB: Yeah, I was playing with some of the 0.0x kernels from cs.hut.helsinki.fi
23:43 <TemptorSent> TBB: Just take a quite browse, you should be able to actuall make sense of the profiles at a glance.
23:44 <TemptorSent> github is pre-surgery, so I'm doing some major cutting of fat and rearranging of profiles right now to make them both slimmer and easier to extend.
23:44 <TBB> probably; I mean, when the purpose for the tool is what it is, and it sounds close to what I do... well, there's not that many different paths to the same goal
23:45 <TemptorSent> TBB: It's a general purpose builder really, it just happens to be doing alpine profiles :)
23:45 <TBB> same for mine
23:46 <TemptorSent> TBB: A few more things that need to be cleaned up before I'm really happy with it, especially in getting rid of variable references in foreign places since they get trashed too easily.
23:46 <TBB> I was doing a project on CentOS, then we switched to Alpine, and all of a sudden another project wanted assistance so I wrote a tool that supported both CentOS and Alpine
23:47 <TBB> and I've been on that road ever since; too busy to properly rewrite the whole thing...
23:47 <TemptorSent> TBB: It should be able to handle parallel building of the profiles with a few lines added and some minor changes to ensure exported globals dont get stepped on
23:47 <scv> i recently quit my last job, but one of the final tasks was porting our entire internal infra from cent6 to alpine
23:48 <TemptorSent> TBB: Yeah, too late for that -- I think I've rewritten all but a couple dozen lines, and added far more.
23:48 <scv> nearly 3:1 consolidation on VM instance size between el6 and alpine for the exact same stack
23:48 <scv> packages all built from scratch
23:48 <scv> (asterisk / management rpc)
23:48 enedil joined
23:48 <scv> not just disk space but runtime memory usage as well
23:48 <TBB> I used to do that, the original installer I wrote for a long since gone version of what I do for a living, it was written in a way to allow one host system to install tens of systems in parallel
23:48 <scv> ksm on the hosts achieving nearly 50% deduplication under alpine
23:48 <scv> very pleased with the results
23:49 <TemptorSent> scv: Oh, you'd love what mkimage does now then.
23:49 <scv> TemptorSent: what do you mean
23:49 <TemptorSent> You can build one-off pre-configured images and overlays direclty.
23:50 <scv> ah that sounds nice
23:50 <TemptorSent> Autogenerate ssh key pairs (host, root user, and root login currently), start the daemons, start the database, etc.
23:50 <scv> we just had an in-house system to build the image in a chroot then boot the instance
23:50 <scv> pretty much same stuff then
23:51 <scv> sounds like i need to take a look at it
23:51 <scv> much better than the old el6 deployments, they were cloning disk images, never regenning ssh keys, same uuids for disks on each vm
23:51 <scv> a real mess
23:51 <TemptorSent> scv right, this lets you configre it on a per-instance level if you want, dumping the output directly to the chroot would be easy.
23:53 <TemptorSent> scv: Yeah, I don't like the concept of sharing host keys they way they're usually done either -- this only keeps the public host key and root user key in the key bin, so you can actually reasonably authenticate.
23:54 <TemptorSent> No later man-in-the-middle because someone snagged your keys.
23:54 <scv> these deployments didn't even really need ssh, probably would've been fine emulating serial consoles to a fifo on the host
23:55 <scv> they're managed completely through the platform rpc
23:55 <scv> s/fifo/socket
23:55 <scv> but w/e not my concern anymore :p
23:55 <TemptorSent> scv: Yeah, that's pretty minimal requirements.
23:55 <scv> they decided to ditch their in-house platform for some 3rd party garbage
23:55 <TemptorSent> :)
23:55 <TemptorSent> That'll bite them in the ass.
23:56 <TBB> that's always fun
23:56 <scv> i spent 15 minutes pentesting it when they setup a demo ... sql injections galore, local file inclusions
23:56 <scv> it's a right gong show
23:56 <scv> i feel really bad for them
23:56 <scv> but again
23:56 <scv> their decision
23:56 <TBB> I just got to demonstrate today how doing some development in-house is beneficial
23:56 <TemptorSent> Just be damn glad you're not there to try to support it when it goes down in flames.
23:57 <TBB> a guy had a problem that required new functionality from the build tools, 10 minutes later he had it
23:57 <scv> oh i'm still on contract with them to maintain the legacy systems until they finish migration, but i refuse to touch the new stuff
23:57 <scv> the new platform comes with a support contract, their engineers are clueless
23:57 <scv> it only runs on ubuntu 14.04, they were having some trouble while doing their setup, apt was segfaulting
23:57 <scv> they sent it back to us, "you need to check your firewall"
23:57 <TBB> but now, time for sleep. Temptor, I'll have a closer look this weekend
23:57 <* scv> headdesk x100
23:58 <scv> on top of that they're putting every single customer on a single monolithic binary, multi-tenant pbx
23:58 <scv> compared to the old platform where each customer has their own dedicated instance, scales out horizontally as much as you want
23:59 <scv> instead let's just jam every customer on the same friggin binary
23:59 <scv> sounds real scalable
23:59 <scv> /rant
23:59 coin3d joined