<    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 24 25  
26 27 28 29 30 31
00:21 mrEngineer joined
00:27 mrEngineer_ joined
00:50 braderhart joined
00:54 cyborg-one joined
00:54 fragtastic joined
01:01 ogres joined
01:31 blueness joined
01:58 mrEngineer_ joined
02:32 s33se_ joined
02:39 vitronic joined
03:36 mdillon joined
03:54 greguu joined
03:59 diego__ joined
04:00 diego__ left
04:01 dirac2 joined
04:02 sparklyballs joined
04:03 ahrs_ joined
04:04 mguentner joined
04:05 diego__ joined
04:06 diego__ left
04:07 diego__ joined
04:08 diego__ joined
04:08 Yzguy joined
04:13 mguentner2 joined
04:20 Emperor_Earth joined
04:33 ahrs joined
05:34 <saintdev> the extended iso doesn't match the sha256
05:38 <saintdev> https://www.irccloud.com/pastebin/K3tNeWpl/
05:53 mrEngineer_ joined
05:59 mrEngineer joined
06:25 mrEngineer_ joined
06:42 Ayyad joined
06:57 bitjab joined
07:04 BitL0G1c joined
07:14 sparklyballs joined
07:39 gogoprog joined
07:46 blackwind_123 joined
08:11 scadu joined
08:15 scadu left
08:27 t0mmy joined
08:36 Ayyad joined
08:37 Mutter joined
08:39 Mutter joined
08:40 FRP joined
08:41 blueness joined
08:48 FRP joined
08:50 FRP-admin joined
08:51 xfix joined
08:52 fhcgbv joined
08:54 fhcgbv left
08:56 FRP-admin joined
09:11 FRP-admin joined
09:11 blueness joined
09:11 BitL0G1c1 joined
09:15 FRP-admin joined
09:15 fragtastic joined
09:16 tw joined
09:17 ncopa joined
09:24 FRP-admin joined
09:28 FRP-admin joined
09:31 lilleman joined
09:32 <lilleman> Hi! I'm trying to start elasticsearch after I installed the package with apk, but I simply cannot find out how
09:32 <lilleman> the bin folder is missing
09:32 <lilleman> I have a /etc/init.d/elasticsearch but I'm not running the rc init system (trying to keep it as basic as possible atm)
09:32 <lilleman> A hint would be awesome :)
09:34 fekepp joined
09:39 <lilleman> According to the package online there should be a bin-folder but I can just find a lib and a module folder (https://pkgs.alpinelinux.org/package/edge/community/x86/elasticsearch)
09:41 FRP-admin joined
09:55 stwa joined
09:55 royger joined
10:00 Ayyad joined
10:03 FRP-admin joined
10:24 danci1973 joined
10:24 <danci1973> Hello...
10:25 <danci1973> How can I map network interface names to MAC's in Alpine 3.5.1 ? I (think) I had /etc/mactab and /etc/mdev.conf in 3.2.3, but can't find that on 3.5.1 ...
10:31 Gk-1wm-su joined
10:37 <BitL0G1c1> lilleman - /usr/share/java/elasticsearch/bin
10:39 blueness joined
10:53 FRP-admin joined
10:55 BlackIkeEagle joined
10:58 BlackIkeEagle joined
11:00 lesion joined
11:01 felixjet joined
11:01 BlackIkeEagle joined
11:06 BlackIkeEagle joined
11:16 BlackIkeEagle joined
11:23 FRP-admin joined
12:01 _ikke_ joined
12:01 blueness joined
12:12 stwa joined
12:21 farosas_ joined
12:26 FRP-admin joined
12:27 gromero joined
12:32 blueness joined
12:34 FRP-admin joined
12:37 <darkfader> is zfs usable atm?
12:38 <darkfader> non-root just data
12:56 FRP-admin joined
13:00 andor2007 joined
13:04 FRP-admin joined
13:12 dirac2 joined
13:13 Berra joined
13:22 m4 joined
13:23 <m4> alpine-extended-3.5.2-x86_64.iso -broken?
13:29 jackmcbarn joined
13:33 <^7heo> m4: #define broken
13:35 <m4> ^7heo: just tested alpine-extended-3.5.2-x86.iso and it works
13:35 <m4> but x86_64 failed to boot ( bad arcive while apk trying to unpack
13:39 <^7heo> m4: I assume you wanted to write "bad archive"
13:39 <^7heo> m4: what did you do, exactly, and when did that happen?
13:39 <m4> yea...
13:39 <m4> ^7heo: nothing, just try to boot iso
13:40 <^7heo> so
13:40 <^7heo> you:
13:40 <^7heo> 1. downloaded the iso from www.alpinelinux.org
13:40 <^7heo> 2. burned the iso on a CD
13:40 <m4> y
13:40 <m4> no
13:40 <^7heo> ah, see?
13:40 <m4> qemu -iso
13:40 <^7heo> I'm asking what you did because it matters.
13:40 <^7heo> we don't know yet what's the problem
13:41 <^7heo> but without proper description, we won't help.
13:41 <^7heo> not that we don't want to...
13:41 <^7heo> ...but we cannot.
13:41 <m4> ^7heo: I just wget & qemu iso
13:41 <m4> only extended x86_64 version failed
13:41 armin joined
13:41 <m4> vanilla works, also x86 for extended
13:42 <m4> so it looks something goes wrong with that iso
13:43 <m4> used https://nl.alpinelinux.org/alpine/v3.5/releases/x86_64/alpine-extended-3.5.2-x86_64.iso t https://nl.alpinelinux.org/alpine/v3.5/releases/x86/alpine-extended-3.5.2-x86.iso
13:44 <^7heo> does "t" mean "and"? :P
13:44 <m4> yes
13:44 <^7heo> ok :D
13:45 <m4> just typo while c/p
13:45 <* ^7heo> is becoming good at guessing
13:45 <^7heo> yeah no worries ;)
13:46 <^7heo> so, you start qemu with `qemu -iso alpine-extended-3.5.2-x86_64.iso`, and next thing you know, before you interact with it in ANY WAY, it crashes on the "bad archive while apk trying to unpack"?
13:46 <m4> no ended with /sbin/init failed
13:47 <m4> I saw BAD ARCHIVE while musl trying to install in /sysroot
13:47 <^7heo> Damn, you're challenging me at guessing again ;)
13:47 <m4> ^7heo: heh,. maybe simple to start qemu -iso ? :)
13:48 <^7heo> no
13:48 <^7heo> I'm at work
13:48 <^7heo> and i'm not paid to troubleshoot alpine.
13:48 <m4> ok
13:48 <^7heo> I'm just being here out of courtesy, in case I can fix something.
13:48 <m4> I just hop here to check if alone with this problem
13:48 <^7heo> but since you're not putting much effort into helping yourself being helped...
13:48 <^7heo> I don't see why I should go the extra mile on my employer's time.
13:49 <dalias> ^7heo, rather than chastizing a user trying to get help it would be nicer to just advise to wait for someone else
13:49 <dalias> it's certainly reasonable that you can't spend your employer's time on this
13:49 <^7heo> dalias: do you expect to have a better chance at guessing what's wrong without info?
13:49 <^7heo> I mean, it's really frustrating not to have more info than "it broke"
13:49 <dalias> no, but someone else might have time for some hand-holding
13:50 <^7heo> of course you can try to reproduce the bug yourself
13:50 <^7heo> but chances are that it's not easy.
13:50 <^7heo> yeah ok.
13:50 <dalias> *nod*
13:50 <^7heo> you make a valid point.
13:50 <m4> ^7heo: why you think so?
13:50 <^7heo> sorry for being edgy, m4; just wait for someone else.
13:50 <^7heo> m4: because based on the information I have
13:51 <^7heo> m4: you might even be trying to boot alpine on qemu -iso on ubuntu on virtualbox on windows on xen on solaris on a sparc.
13:51 <^7heo> I don't even know if you are doing that or not.
13:51 <m4> ^7heo: ?
13:51 <^7heo> you just wrote the bare minimum info that was asked, leaving any detail to the fantasy of the person who would help.
13:52 <^7heo> and I'm trying to tell you that people don't necessarily have the time or the patience to do that.
13:52 <^7heo> and right now, I have to do something else.
13:52 <m4> what you want a book about iso don't boot?
13:52 <m4> I tried on real box and then checked with qemu
13:52 <^7heo> I'm not the one having a problem to boot an iso and explaining what is wrong.
13:52 <m4> x86 version work, vanilla ... and you need more info??
13:53 <^7heo> yeah.
13:53 <^7heo> Read on how to report a bug.
13:53 <^7heo> it's not "shit broke"
13:53 <^7heo> by a long shot.
13:53 <^7heo> now, I'm away.
13:54 <^7heo> (and just as a last comment: "I tried on real box and then checked with qemu". That's something you didn't say before you started trolling me)
13:56 <avih> m4: post the exact command[s] you run, then what error messages (or crashes) you get, etc.
13:56 <avih> "broken" could be a 1000 different things.
14:03 <m4> avih: I did nothing expect download iso , and run
14:04 <m4> only extended x86_64 version failed
14:04 <m4> ERROR: musl-1.1.15-r6: BAD archive
14:04 <m4> ERROR: busybox-1.25.1-r0.post-install: script exited with error 1
14:04 <avih> that's the first message you see after you boot the iso?
14:04 <m4> yes
14:05 <avih> or does it make some progress and then display this message?
14:05 <m4> if left quiet
14:05 <avih> m4: was it you who mentioned a sha mismatch?
14:06 dnel joined
14:07 <avih> no, it wasn't you. try to check the sha256 sum. maybe some mirror got a corrupt image
14:13 <m4> tnx avih
14:13 <avih> did you find the issue then?
14:13 <m4> http://dl-3.alpinelinux.org/alpine/v3.5/releases/x86_64/alpine-extended-3.5.2-x86_64.iso <--correct sha
14:14 <m4> https://nl.alpinelinux.org/alpine/v3.5/releases/x86_64/alpine-extended-3.5.2-x86_64.iso <--broken
14:14 <avih> and the one with correct sha works?
14:15 <m4> yes
14:15 <m4> works without problem
14:15 <m4> so obviously problems with mirrors
14:15 <avih> k
14:16 <avih> ncopa: ^ corrupt image on the nl mirror
14:16 <^7heo> don't we have a hash checking after mirroring?
14:17 <avih> m4: just in case, did you try downloading it again? maybe your download is corrupt but ok on the mirror itself?
14:17 <^7heo> imho that is more likely.
14:18 <avih> ^7heo: he's the second user reporting a sha mismatch
14:18 <^7heo> yeah, ISPs fuckup regularly.
14:18 <avih> today
14:18 <^7heo> ah.
14:18 <^7heo> then we have to prompt ncopa for a hash-check after mirror sync.
14:18 <^7heo> which I thought we would have
14:19 <^7heo> but at the same time, our infra isn't exactly unified :P
14:19 <^7heo> so I wouldn't be surprised if stuff would be amiss.
14:21 <avih> i'm getting diff sha256: 9bfa18611526e76e105ae64daef2bfee34b84a23e030eb4ccc7f36b8e5f23b54 on the nl one and f5d2d5dc518c070a3b34e0787386744326177c1d61717bedf52e780e7b549954 on the main one.
14:22 <avih> so likely a corrupt image and not an isp issue
14:22 <avih> s/main/dl-3/
14:24 ogres joined
14:33 <m4> avih: tried several times... (was not single shoot
14:33 <avih> yeah, i can reproduce mismatched sha on the nl one
14:34 <m4> I think yday download from diff mirror ( but can't find which one
14:35 <m4> so perphaps one more mirror affected
14:36 blueness joined
14:41 FRP-admin joined
14:50 blueness joined
14:57 Skele joined
15:00 nanohest joined
15:02 c00kiemon5ter joined
15:19 <ncopa> avih: thanks for reporting that, im checking all of the images now
15:19 <avih> k
15:19 <ncopa> alpine-extended-3.5.0_rc3-x86_64.iso: FAILED
15:19 <ncopa> sha256sum: WARNING: 1 of 1 computed checksums did NOT match
15:20 <ncopa> alpine-extended-3.5.2-x86_64.iso: FAILED
15:20 <ncopa> sha256sum: WARNING: 1 of 1 computed checksums did NOT match
15:20 <avih> :/
15:20 <ncopa> 4 of them failed
15:20 <ncopa> i suspect its disk error of some sort
15:20 <avih> at least it's good to know ;)
15:22 <ncopa> yes. thanks
15:24 FRP-admin joined
15:26 <^7heo> ncopa: don't we have automatic checking?
15:29 <ncopa> no, we dont automatically check all the mirrors
15:30 <ncopa> i suppose we could automatically verify the images on master mirror
15:30 <ncopa> or we could check via cronjob or similar
15:33 <clandmeter> are they broken on master mirror?
15:34 <^7heo> clandmeter: nah apparently only on secondaries.
15:35 <^7heo> ncopa: can't we use the same process that updates the mirrors?
15:36 <ncopa> ^7heo: we dont have control over all mirrors
15:37 <^7heo> right.
15:37 <^7heo> I tend to forget that.
15:38 <avih> isn't there some mirroring "protocol" which includes checksums?
15:38 <avih> maybe the master should have the checksums in some file/format (apparently other than the current checksum files, assuming there's such method)
15:57 <^7heo> avih: I'd assume so yes.
15:57 <^7heo> (about the protocols)
16:00 <avih> if the issue is damaged disk though, then it could have gotten damaged after the clone, or even during the clone but the checksum would be from the cached version of the file (which just got written, so it might be fine)
16:03 <^7heo> true.
16:04 <^7heo> maybe sha*sum actually reads from disk
16:04 <^7heo> (and by that I mean forces the kernel to drop the cache)
16:08 <dalias> that can't be done by a non-privileged process
16:16 <^7heo> ah right.
16:17 <^7heo> but then sha*sum could be suid
16:17 <^7heo> and I didn't check that.
16:18 FRP-admin joined
16:19 <avih> so i guess a day or so after ISO updates, something central (in alpine's control) would verify all the mirrors. apk's are less of an issue since they include their own verifications.
16:19 <^7heo> well, in Alpine, at least, it is a link to busybox, not to bbsuid.
16:20 <dalias> sha*sum doing that would be a clear violation of clean functionality boundaries
16:24 <^7heo> dalias: possibly, but also returning more reliable results.
16:26 mikeee_ joined
16:27 <dalias> that could be said about every single program
16:28 <dalias> it's not a valid argument for having every program override/suppress fs cache
16:28 <dalias> if you have a specific deployment need for that, you'd use a custom os configuration or custom os
16:35 tw joined
16:45 eripa joined
16:49 <^7heo> dalias: right
17:14 <hiro> did the musl fix for non-standard page-size finish propagating to alpine?
17:17 <^7heo> hiro: now that dalias is around, it's a good time to ask ;)
17:18 <dalias> not sure; check git
17:18 <dalias> http://git.alpinelinux.org/cgit/aports/tree/main/musl/
17:18 <dalias> looks like not :(
17:19 <hiro> the last real change was 11 days ago i guess
17:20 <hiro> now i know what to watch :)
17:20 <hiro> thanks.
17:20 <dalias> np
17:21 lesion_ joined
17:25 bluetazmanian joined
17:25 <bluetazmanian> Hey room
17:31 <hiro> i saw an open issue about nscd
17:32 <hiro> in general i made bad experiences with software interfacing the complexity hidden behind nscd :(
17:32 <hiro> i'd hope these kinds of interfaces that pull in all this crud would stay unsupported.
17:33 <dalias> you probably misunderstand
17:34 <hiro> dalias: very likely :)
17:35 <dalias> nscd was taken as the only existing protocol precedent for a configuration-free alternate backend for passwd/group db
17:38 <dalias> other options for allowing alt pw/grp backends would have required inventing new conventions for where special files/sockets/etc reside and how to interpret them
17:38 <dalias> and would not have facilitated being able to drop musl-linked binaries onto an existing glibc system
17:40 <hiro> sound
17:42 <dalias> we don't do any complex caching or use of other wacky record types over nscd
17:42 <dalias> it's purely used as a lookup protocol for pw/grp records
17:43 <hiro> ah, so the name doesn't fit so well any more
17:43 <hiro> i hoped this would be the case
17:44 <hiro> though the really frightening stuff might not be nscd itself but the database systems behind
17:45 <hiro> but i guess people really need this feature :(
17:45 <dalias> yes, ldap user backends are common in large institutions
17:46 <hiro> i also dislike the idea that coworkers are free to login to your machine
17:46 <hiro> in general...
17:46 <dalias> they wouldn't necessarily be
17:46 <hiro> it would be fine to have a *shared* system that everybody can log in to, but not each workstation
17:46 <dalias> you might just be using coordinated uids across all systems so that network shares can have meaningful permissions
17:46 <hiro> right
17:46 <dalias> passwd db does not grant login rights
17:47 <hiro> here for example i can just become any user because i have root perms
17:47 <hiro> so then i can access *every* network share :(
17:47 <dalias> well that's a broken setup
17:47 <hiro> yeah
17:48 <hiro> i'd rather have no pretense of security in the first place, then everybody would just not put sensitive/security-needing files in the first place
17:48 <hiro> but this way it *looks* secure, but isn't anyway.
17:48 <dalias> nfs is broken like that. samba/cifs less so
17:48 <dalias> nfs should basically just never be used. it's awful
17:48 <hiro> nfs basically makes your system including all workstations one big entity
17:49 <hiro> which means that /etc/passwd could just be served by nfs
17:49 <hiro> but they don't even do that, they pretend it's secure :(
17:49 <hiro> *more secure
17:49 <dalias> do you really want ls to parse a 100000-line passwd file once per line it prints?
17:49 <hiro> good point.
17:49 <dalias> (and even worse, do it over the network)
17:50 <hiro> small in my case here, but big corporations probably shouldn't use either nfs nor this large passwd file
17:50 <dalias> flat file does not scale beyond a few (hundred) users at most
17:50 mouthbreather joined
17:50 <dalias> i've seen university setups where every staff, faculty member, and student, past or present, had a unique uid
17:51 <hiro> yeah, might be. networks got fast also, so perhaps it can work also in a company with 1000 entries
17:51 <hiro> but at this size you'd want more isolation anyway
17:51 <hiro> no sense in trusting everybody
17:51 <dalias> trusting everybody is not part of it
17:51 <dalias> rather, having unique ownership ids is
17:51 <hiro> (using nfs means you trust everybody)
17:51 <dalias> right
17:51 <dalias> nfs is awful
17:52 <dalias> but there are plenty of reasons for institution-wide shared user db that do not entail using nfs or letting anyone login to any machine
17:52 <hiro> and i could imagine sharing passwd via nfs if security wasn't important
17:52 <hiro> but if security isn't important individual workstations should just have individual passwd
17:52 <dalias> i think you have a serious misunderstanding
17:53 <dalias> passwd has nothing to do with access control
17:53 <hiro> s/isn't/is/
17:53 <dalias> it maps user names to uids and info like realname, preferred shell, etc.
17:53 <hiro> well, it often comes with shadow :)
17:54 <hiro> and traditionally it had that jobn
17:54 <dalias> shadow does not support nscd backend in musl because there's no secure way to do it
17:54 m4 joined
17:54 <hiro> i just don't want to list passwd,group,shadow all the time
17:54 <dalias> you should not be using password authentication anyway
17:54 <hiro> hmm?
17:54 <hiro> i like passwords.
17:55 <dalias> you can use a password for logging into your own laptop/workstation console
17:56 <hiro> i know some people use their ssh key's keyphrase to unlock their computers :)
17:56 <dalias> but for remote logins they're really bad in terms of security properties and don't scale well
17:56 rafalcpp joined
17:56 <dalias> pubkey should really be used for remote auth
17:56 <hiro> ah no, actually i guess they use their ssh key, but they input their keyphrase to allow it's decryption
17:57 <hiro> ah, and i agree with you.
17:57 <hiro> i only have passwords locally
17:57 <hiro> when i log into something else i just use public-key stuff
17:58 <hiro> back to the ssh stuff: it's some feature so you don't need both ssh keyphrase AND a login to your user account
17:58 <hiro> some pam plugin or something
17:59 <hiro> (i'd never use it obviously, but whatever :)
17:59 <hiro> that feature was amusing to me when i heard it
18:05 <tw> another interesting sshkey+pam hack is requiring an authorized ssh-agent for remote sudo in addition to a password.
18:07 <tw> This is interesting because you can use ssh-CA pubkeys in the system authorized_principals file and put lifetimes on ssh keys via certificates.
18:12 <hiro> hehe
18:12 <hiro> hackhackhackhack
18:12 <hiro> in the end all of this still scares me
18:13 <hiro> if there is no db that speaks a sane protocol there shouldn't be any support for such db imo :P
18:13 <hiro> but i'm late to the party, i found now an old thread from 2012 talking about this
18:15 sergey_ joined
18:31 FRP-admin joined
18:52 FRP-admin joined
18:53 bluetazmanian joined
18:53 FRP-admin_ joined
18:54 bluetazmanian joined
19:05 gromero_ joined
19:09 bluetazmanian joined
19:13 <bluetazmanian> Hi, Help needed. hhvm-help, I'm very close to compiling HHVM on alpine linux (Edge). It fails when trying to compile webscalesqlclient due to a missing dependency libncurses5-dev. I've tried replacing it with ncurses5-libs to no success. Any hints?
19:14 <bluetazmanian> I've been on it for a week now when time permits, and I'm very close. It would nice to have HHVM on Alpine.
19:15 stwa joined
19:22 dcb_ joined
19:23 <dcb_> hi, having again problems recovering a lvm install after a bad kernel update
19:24 <dcb_> so I’ve booted from a live image, mounted the lvm root, /dev, /proc and /sys and chrooted
19:25 <dcb_> I tried to fix the kernel but I get the error that it cannot access /dev/sda1 (which is the /boot partition)
19:25 bluetazmanian joined
19:25 <dcb_> I even tried to fix it without chroot
19:25 <dcb_> with apk -p /mnt fix linux-grsec but I get the same error about /dev/sda1
19:26 <dcb_> I’m completelly lost as I was able to fix another machine without a hich
19:26 nanohest joined
19:27 <TemptorSent> dcb_: Have you tried unmounting boot first?
19:28 <TemptorSent> dcb_: ...and do you have /proc, /dev, & /sys mounted?
19:28 cyborg-one joined
19:28 <dcb_> if I don’t mount it it will just install everything in the /boot folder and then fail with the message that it can’t access lv_root
19:29 <dcb_> yep I have mounted /proc /dev and /sys in chroot
19:29 <TemptorSent> dcb_: What tool are you using to try to install the bootloader?
19:30 <dcb_> apk fix linux-grsec
19:30 <TemptorSent> dcb_: I'm not much on the lvm side, but I might be able to figure it out..
19:30 <TemptorSent> dcb_: Is that running 'update-kernel' as expected?
19:30 <dcb_> it’s really odd that on an identical machine I was able to fix it straight away
19:31 <TemptorSent> And what is the contents of /etc/mkinitfs/mkinitfs.conf?
19:32 <TemptorSent> I'm going to take a SWAG that lvm isn't enabled in the mkinitfs features -- check the features.d directory.
19:32 <dcb_> yes, it is and at some point it just says extlinux: cannot open device /dev/sda1
19:33 <dcb_> I’ll go check those, brb
19:33 <TemptorSent> dcb_: the can't open device bit is odd.. can you (g)fdisk /dev/sda and see everything as expected?
19:35 bluetazmanian joined
19:37 m0e joined
19:38 fekepp joined
19:38 Emperor_Earth joined
19:39 blueness joined
19:41 <dcb_> in chroot fdisk /dev/sda says operation not permitted
19:42 <dcb_> also if I try to mount the boot while in chroot again doesn’t work
19:42 <dcb_> it behaves as if I’m not root
19:46 <TemptorSent> dcb_: I suspect grsec is the culprit there.
19:46 <TemptorSent> dcb_: I'm sure there's a way of allowing it, but I can't say I know it off the top of my head.
19:47 <dcb_> should I try with a vanilla live?
19:48 armin joined
19:48 fekepp joined
19:50 mrEngineer joined
19:55 czart__ joined
20:00 <TemptorSent> dcb_: That might be an option, or just turn of grsec from the kernel command line.
20:01 <TemptorSent> dcb_: I'm sure the 'right' way includes toggling things in securityfs or some such. I haven't had to worry about that particular issue yet :)
20:03 Berra joined
20:20 ganlub joined
20:20 <dcb_> yep, that did it. finally it’s fixed with vanilla live
20:22 blueness joined
20:23 <ganlub> hi everyone! I'm looking to use alpine on rpi zero, is it there any way to enable ssh to be able to install remotely?
20:25 <TemptorSent> dcb_ : Good deal!
20:26 <TemptorSent> ganlub: I'm working on the image building system right now actually, with autogenerated ssh keys :)
20:26 tobbez joined
20:27 <ganlub> TemptorSent: sounds good! so at the moment I'll need keyboard/screen access right?
20:28 <TemptorSent> ganlub: Once I actually have it working, you should be able to build an image and go -- but it's still a little ways off.
20:29 m4 joined
20:31 <ganlub> TemptorSent: then I wish you good luck with that ;) I'm also new with all of this, I only used alpine with docker stuff
20:31 <TemptorSent> ganlub : Tree here -- currently broken at random as major revision get done: https://github.com/TemptorSent/aports/tree/mkimage-refactor-scripts/scripts/mkimage.
20:32 <TemptorSent> ganlub: Part of the reason for the rewrite is to make generation of custom VM images easy.
20:32 bluetazmanian joined
20:34 <TemptorSent> ganlub: I'm currently working on debugging / extending bootloader support.
20:35 <ganlub> TemptorSent: it's a bit out of my scope.. I wish I could help
20:36 <TemptorSent> ganlub: No worries -- I need testers on various archs to let me know what works and what doesn't once it stabilizes a bit.
20:36 <ganlub> TemptorSent: I was just about to follow https://wiki.alpinelinux.org/wiki/Raspberry_Pi but then I realized that I'd need to enable ssh bc I don't have minihdmi to hdmi adapter for the rpi zero w 🤕
20:37 <ganlub> TemptorSent: sure thing!!!
20:37 lesion joined
20:47 tmh1999 joined
20:49 fabled joined
20:53 <yGweSm1OzVHe> dcb_: this is a better solution than plain vanilla kernel: echo 0 >/proc/sys/kernel/grsecurity/chroot_deny_chmod
20:54 <dcb_> noted. thanks!
20:55 <yGweSm1OzVHe> there's also other chroot settings in that directory, also for mknod and other stuff that might be useful during install/adding pkgs
20:55 <yGweSm1OzVHe> don't for get to enable the settings after you done
20:57 blackwind_123 joined
20:58 nanohest joined
21:01 dlaube joined
21:12 <lilleman> BitL0G1c1: I have no "bin" in /usr/share/java/elasticsearch , I only have "lib" and "modules"
21:12 <lilleman> The only thing I do is:
21:12 <lilleman> docker --rm -it run alpine sh
21:13 <lilleman> apk update && apk add elasticsearch
21:13 bluetazmanian joined
21:37 bluetazmanian joined
21:40 Tsutsukakushi joined
21:40 triple joined
21:46 t0mmy joined
21:46 bluetazmanian joined
21:46 Nobabs27 joined
21:47 Tsutsukakushi joined
21:47 triple joined
22:06 blackwind_123 joined
22:09 bluetazmanian joined
22:13 <Spydemon> Hello. :) I was wondering why ifup and ifdown commands need a TTY for being used… Does someone here has the answer?
22:16 <TemptorSent> Spydemon: They should be able to run lights-out from a script -- what're you running into/
22:18 <Spydemon> TemptorSent, I'm just trying to launch a `ifup eth0` inside a LXC container. But you're right: it should be able to be executed from a script because OpenRC init script did so.
22:19 <Spydemon> But according to strace, I hit a ENOTTY when I try to launch the command manually. :(
22:19 triple joined
22:20 <TemptorSent> Spydemon: Odd.. did you try redirecting to /dev/null?
22:20 Tsutsukakushi joined
22:21 kahiru joined
22:21 <TemptorSent> Spydemon : Are there any enviroment variables set/unset that could be confusing it?
22:24 <c00kiemon5ter> ¨μ
22:27 kahiru joined
22:27 laj joined
22:31 ogres joined
22:37 <Spydemon> TemptorSent, it seems that you went right: I figure out that my environment variables were (obviously…) the sames than on the host. Unseting SSH_TTY seems to solve the issue.
22:38 <Spydemon> Well… I still hit a ENOTTY but the write in /var/run/ifstate occurs now.
22:40 <TemptorSent> Spydemon: Odd, did you try redirecting stdin/stdout/stderr to /dev/null?
22:41 <TemptorSent> Spydemon: Often that will trigger code that disables TTY processing.
22:46 <Spydemon> TemptorSent, no, it doesn't change anything in my case to redirect the output.
22:46 <Spydemon> The variable to unset is actualy SHELL, not SSH_TTY.
22:47 <TemptorSent> Spydemon: Is TERM set by chance?
22:50 <TemptorSent> Spydaemon: Can you give me the command line you're using for it?
22:52 <Spydemon> TemptorSent, yes, TERM='xterm-256color'
22:52 <Spydemon> Do you want what command line ?
22:52 <Spydemon> I'm just typing `ifup eth0` in ash.
22:53 <Spydemon> (or `ifup eth0 > /dev/null`, `strace ifup eth0`)
22:53 <TemptorSent> try echo -n | ifup eth0
22:53 <TemptorSent> echo -n | ifup eth0 2>&1 > /dev/null
22:55 <Shiz> ifup eth0 </dev/null is more effective for that
22:55 <Spydemon> TemptorSent, none of your options work if I keep the SHELL variable set.
22:56 <TemptorSent> spydaemon: Odd.. that's bad behavior.
22:56 <TemptorSent> Shiz : good point :)
22:58 <Spydemon> Yes… It surprising that I seem to be the single one that experience this trouble.
22:58 <Spydemon> Shiz, your option also doesn't works. ^^"
23:00 <TemptorSent> Try this: '(unset TERM; unset SHELL ; ifup eth0 < /dev/null)'
23:01 <Spydemon> This work.
23:01 dirac1 joined
23:02 <TemptorSent> Spydemon: Try this too, which is better if it works: env -i ifup eth0
23:03 <TemptorSent> Spydemon: It depends on if anythign in the environment is needed (USER perhaps?)
23:03 <dirac1> Hi guys anyone has installed Alpine in this kind of devices https://ptpb.pw/IPO6 ?
23:04 <dirac1> I'm interested in creating a Security gateway / firewall with it..
23:05 mdillon joined
23:06 <TemptorSent> dirac1: Link is getting blocked by firewall, fingerprint HTML/Refresh.BC
23:06 <Spydemon> TemptorSent, yes `env -i /sbin/ifup eth0` also works.
23:07 <TemptorSent> Spydemon: You might just run the whole script with that if you can get away with it.
23:08 <Spydemon> TemptorSent, yes I can. I was just wondering why this strange behavior is present. :-/
23:08 <dirac1> I'll paste the full link
23:09 <dirac1> https://www.aliexpress.com/store/product/QOTOM-Dual-LAN-Mini-Computer-with-Bay-Trail-J1800-J1900-Processor-onboard-Fanless-mini-industrial-PC/108231_32694016045.html?spm=2114.12010612.0.0.QoyheS
23:09 <Spydemon> OpenRC manages it fine, so it is ok for automation. We just need to think about it when debugging… ^^"
23:09 <Spydemon> Tank for your help, TemptorSent!
23:10 <TemptorSent> dirac1: Ahh, gotcha (even without trying to type that)
23:10 <TemptorSent> Spydemon: No problem... I'm having fun trying to debug shellscripts interactively by sourcing them in.
23:11 mdillon joined
23:11 <TemptorSent> dirac1: Come up with a set of packages and config needs and we'll see what I can do :)
23:12 <dirac1> When you reffer to packages.. you mean like iproute, iptables? alpinewall..?
23:18 <TemptorSent> dirac1: Yes. I'm working on a rather more flexible image builder, so if you can come up with a set of features and packages needed for each, I thnk it would be fairly straightforward.
23:19 <bougyman> eifjccfvcitjjdcllbebrrtbvifrthlknnuejrrkvehh
23:20 <dirac1> Well my main interest with this is create a cheap/low consume/3rdWorldSolution , Access Security Router... main features: Static Routing,Vlan Routing,Firewall,Vpn,DDNS and the basic stuffs dhcp,NAT
23:21 <dirac1> (This will be my Pre-grade thesis)
23:22 <dirac1> I'll have to create a HTML, GUI... and test capabilities on SOHOs and middle class industries
23:24 <TemptorSent> dirac1: I believe some of that work may already exist, so you don't need to entirely reinvent the wheel.
23:25 <dirac1> Yup... Pfsense,Sophos..
23:26 <dirac1> Those are big companies who offer the firewall OS services.
23:27 <TemptorSent> dirac1: While I haven't tried it yet, the acf framework may be a place to start.
23:28 <TemptorSent> It appears to already support VOIP applications
23:28 <dirac1> acf?
23:29 <TemptorSent> Check the alpine wiki - ACF
23:29 <TemptorSent> Alpine Configuration Framework
23:31 <dirac1> Ok ok i can create the GUI design using ACF?
23:35 <TemptorSent> dirac1: That's what it look like to me :) I'll have to dig into that after I get done playing with the low level code.
23:36 <TemptorSent> It might take a bit of work, butI could see integrating it with the image buildng setup and features directly.
23:37 bluetazmanian joined
23:37 <TemptorSent> You might want the check with the devs on the status of the project, the wiki is horribly out of date.
23:39 <dirac1> The ACF project?
23:40 <TemptorSent> Yeah, what's in the tree may be rather different than what the wiki documented.
23:41 <TemptorSent> For instance, you really don't want to use the wiki's info on generating .isos ...that's how I got started on my project in the first place :)
23:45 <dirac1> Ok ok :D
23:55 lesion joined
23:58 scadu joined
23:59 dirac1 joined