gch9812132 has quit [Read error: Connection reset by peer]
Misanthropos has joined #openwrt-devel
PaulFertser has joined #openwrt-devel
PaulFertser has quit [Ping timeout: 272 seconds]
goliath has quit [Quit: SIGSEGV]
PaulFertser has joined #openwrt-devel
victhor has quit [Ping timeout: 246 seconds]
ephemer0l_ has quit [Ping timeout: 265 seconds]
danitool has quit [Remote host closed the connection]
Misanthropos has quit [Ping timeout: 272 seconds]
hbug__ has joined #openwrt-devel
hbug_ has quit [Ping timeout: 240 seconds]
black_ant has quit [Ping timeout: 246 seconds]
tobleminer-tSYS has quit [Quit: AS4242423214]
tobleminer-tSYS has joined #openwrt-devel
Misanthropos has joined #openwrt-devel
gch981213 has quit [Read error: Connection reset by peer]
gch981213 has joined #openwrt-devel
Darkmatter66_ has joined #openwrt-devel
Darkmatter66 has quit [Ping timeout: 260 seconds]
embargo has joined #openwrt-devel
Dagger has quit [Quit: Quitting]
Dagger2 has joined #openwrt-devel
Dagger2 is now known as Dagger
ephemer0l_ has joined #openwrt-devel
Tusker has quit [Read error: Connection reset by peer]
dangole has quit [Remote host closed the connection]
Tusker has joined #openwrt-devel
Acinonyx_ has quit [Ping timeout: 256 seconds]
Acinonyx has joined #openwrt-devel
nitdega has quit [Quit: ZNC - 1.6.0 - http://znc.in]
nitdega has joined #openwrt-devel
kubrickdave_ has joined #openwrt-devel
kubrickdave has quit [Ping timeout: 272 seconds]
<damex>
Grommish_: maybe, but actual commit that broke it is the one that enabled procd-ujail procd-seccomp globally (for 'non-small-flash devices')
dansan has quit [Ping timeout: 258 seconds]
dansan has joined #openwrt-devel
lep-delete is now known as Guest88073
aszeszo has joined #openwrt-devel
nitroshift has joined #openwrt-devel
mwarning has joined #openwrt-devel
mwarning has quit [Ping timeout: 246 seconds]
fork has quit [Quit: Bye.]
fork has joined #openwrt-devel
valku has quit [Quit: valku]
ivanich has joined #openwrt-devel
Borromini has joined #openwrt-devel
Ycarus has joined #openwrt-devel
aszeszo has quit [Quit: aszeszo]
muhaha has joined #openwrt-devel
ivanich has quit [Ping timeout: 272 seconds]
rsalvaterra has joined #openwrt-devel
eduardas has joined #openwrt-devel
black_ant has joined #openwrt-devel
black_ant has quit [Changing host]
black_ant has joined #openwrt-devel
nast has quit [Read error: Connection reset by peer]
Night-Shade has quit [Ping timeout: 260 seconds]
Redfoxmoon has quit [Ping timeout: 258 seconds]
veonik has quit [Ping timeout: 260 seconds]
veonik has joined #openwrt-devel
flx has quit [Ping timeout: 260 seconds]
Night-Shade has joined #openwrt-devel
flx has joined #openwrt-devel
ivanich has joined #openwrt-devel
Redfoxmoon has joined #openwrt-devel
aszeszo has joined #openwrt-devel
feriman has joined #openwrt-devel
<eduardas>
hello, what do you consider the best embedded platform to start learning OpenWrt development? i.e. hich one has the best support and implementation?
<PaulFertser>
eduardas: you can learn OpenWrt development without an embedded platform, it runs nicely on amd64 targets.
<eduardas>
PaulFertser: I understand that... that is why explicitly stated I'm looking for an embedded target because I want to learn some embedded specifics too
<eduardas>
like how raw NAND is managed under OpenWrt, etc.
<damex>
it is more like <how linux imanages raw nand>
<eduardas>
damex: yes, but as far as I know OpenWrt has some non-mainline patches for MTD
<damex>
eduardas: it differs by device. it is highly prefferable to not patch anything
<eduardas>
damex: yes, so perhaps you can suggest an embedded platform that does not require those
<PaulFertser>
eduardas: but if the target you choose has already everything working properly then you won't have much motivation to learn. It's probably better to get some poorly supported (in the area of your interest, e.g. NAND) target and work on adding support for it.
<PaulFertser>
I guess damex learnt a lot while trying to make those boards supported :)
<eduardas>
PaulFertser: makes sense
<eduardas>
PaulFertser: what would you consider the best OEM OpenWrt fork?
<eduardas>
PaulFertser: I'm currently considering to buy the Turris Omnia router
<eduardas>
PaulFertser: since they boast they use open firmware
<PaulFertser>
eduardas: it's probably nice and all, but probably a bit overpriced, and also I'm personally a bit disappointed that they're not trying harder to be closer to mainline.
<PaulFertser>
OTOH it might be a good learning opportunity if you add the missing bits (like SFP support) properly I guess.
<Borromini>
eduardas: gl.inet sticks pretty close to vanilla openwrt as well afaik
<PaulFertser>
I'd say it's just that their boards are so simple that they do not need any special support :)
<Borromini>
:P
<PaulFertser>
btw, I've recently tried using an SFP module that has regular RJ-45 for wired GigE. Pretty handy for testing.
<eduardas>
Borromini: good to know... thanks... have not even heard of this company and product before
<damex>
Borromini: sadly they don't always give you option with PoE
<damex>
Tapper: you can revert last commit in a tree (should fix the issue)
<ynezz>
so which one to revert?
<ynezz>
this one 6a56a6eb30799fcec9eecc3ee860dc4d8a5d952a?
<damex>
yeah, i reverted that one and it worked again on octeons
<ynezz>
can you add your suggested-by: ?
<Tapper>
ynezz I will just hang on for a fix
<damex>
ynezz: you can revert commit?
<ynezz>
yes, doing that right now
<ynezz>
Suggested-by: Roman Kuzmitskii <damex.pp@icloud.com> is that ok?
<damex>
ynezz: sure
mwarning has joined #openwrt-devel
<rsalvaterra>
This basically broke sysupgrade everywhere, I see.
<rsalvaterra>
Yesterday I has problems with two ath79 devices.
<damex>
so i did only test on octeons and reverting 6a56a6eb30799fcec9eecc3ee860dc4d8a5d952a brings them back. fresh install from ram and sysupgrade too
<ynezz>
ok, thanks a lot
<ynezz>
gotta go
<rsalvaterra>
Wait, I still think this revert won't fix the underlying issue.
<rsalvaterra>
Like I wrote yesteday, ubus started running under a dedicated user, not root. On sysupgrade, /etc/{groups,passwd,shadow} are unconditionally backed-up and restored. When they're restored, they don't have the new user.
<rsalvaterra>
Does this make sense?
Redfoxmoon has quit [Changing host]
Redfoxmoon has joined #openwrt-devel
<Borromini>
sounds like a there's a migration mechanism missing
<damex>
rsalvaterra: yeah, it probably won't fix it completely but sysupgrade should work after that revert.
<stintel>
rsalvaterra: this is a very old and very known issue
<rsalvaterra>
Borromini: definitely.
<rsalvaterra>
stintel: Yes, I can see that now, after being bitten twice by it. :)
<stintel>
annoying rightr
<stintel>
I wrote about it in some ticket
<rsalvaterra>
So, we need to boot in failsafe mode, tweak the groups/passwd/shadow files manually and reboot.
<rsalvaterra>
damex: It works because the flash was reset and the correct files were read from /rom/etc. After a reset, everything will work again.
<stintel>
but apparently I don't speak English because I don't they got it
<stintel>
feel free to explain it better ¯\_(ツ)_/¯
<rsalvaterra>
Spot-on, stintel!
gch9812133 has joined #openwrt-devel
<damex>
rsalvaterra: i tried sysupgrade and fresh installs with procd-ujail and procd-seccomp, and without
gch981213 has quit [Read error: Connection reset by peer]
gch9812133 is now known as gch981213
<damex>
it worked only without procd-ujail and procd-seccomp. although it is not a proper fix but let's fix one problem at a time
<stintel>
maybe users can be added by uci-defaults to avoid this problem
<rsalvaterra>
damex: I don't user ujail/seccomp.
<rsalvaterra>
*us
<rsalvaterra>
*use
<rsalvaterra>
Gah… fat-fingered…
<damex>
rsalvaterra: me neither. it got forced on all highmem devices by that commit
<stintel>
ynezz: thanks for reverting that commit
<karlp>
stintel: any ideas on net-snmp snmpd not answering requests on reboot on 1907? (if you've even seen the ticket?)
<stintel>
we really need better testing
<stintel>
karlp: I've seen the mail, I'm still in crisis situation at work + don't run 19.07 so I will not be of any help any time soon :(
<karlp>
no stress.
mwarning has quit [Ping timeout: 272 seconds]
<karlp>
soooner or later I'll just do a new release of my own that just forcibly resets it until it answers, but it's weird, it's all the way along 1907.
<karlp>
stintel: are you already running ~master on your production stuff?
<stintel>
karlp: I'm always running master on all my stuff
<karlp>
too much adventure for me :)
<stintel>
it breaks all the time, but at least someone notices it then
<stintel>
but yeah, too much adventure/frustration, even before this stuff going on at work I was not doing much openwrt related stuff anymore due to the constant need for yak shaving when trying to actually get some work done
<karlp>
I feel ya
<damex>
karlp: what did you do to snmpd so it is in that state? i am using snmpd on all devices here
<damex>
edgerouter-x runs snmpd on 19.07 and seems to be fine
<karlp>
just reboot.
<karlp>
completely stock 19.07 with snmpd added, no othe rpackages, no other config.
<karlp>
responds on first boot, reboot -> non-responsive until it's restarted.
<damex>
karlp: do you have enough memory? and did you install extra mibs?
<karlp>
I have enough memory when I've got all my own apps running too, and it's only on reboot, and /etc/init.d/snmpd restart will instantly restore things until you reboot next.
<damex>
karlp: did you try with actual 19.07 release?
<damex>
not self built but an official build from a mirror?
<karlp>
I don't really see why I should.
<karlp>
but hey, why not, I can retest more
<damex>
if you have <64M or even <128M of ram - you might have issues with snmpd starting with extra mibs present
<damex>
you don't install them so it is not the case
<n4gi0s>
lynxis Still analyzing what they sent me. Looks like more than just GPL code to me, I'm checking if I'm allowed to upload it. If you are really interested you can contact me via pn.
<stintel>
karlp: I think I've seen your problem on master even
<stintel>
karlp: but I don't exactly recall which device(s)
<stintel>
ath79 sounds like it might be
<karlp>
+I only tried master briefly, and it seemed to work, but didn't try it much.
<karlp>
yeah, I'm on ath79
victhor has joined #openwrt-devel
<karlp>
damex: yes. just reflashed the 19.07.4 download, opkg update and opkg install snmpd, and it's failing to respond after reboots. (unsuprisingly :)
Redfoxmoon has quit [Read error: Connection reset by peer]
<damex>
weird. i rebooted er-x '10 days 20 hours 59 minutes 39 seconds' ago (it is on 19.07 release) and it brought up snmpd just fine (i haven't even though about checking it since librenms didn't report it
<damex>
karlp: does the process actually run?
<karlp>
I wsa surprised when it was reported to me too :)
<damex>
karlp: if request is going through and arrive at 161 port (udp) and go back too
<karlp>
the request arrives at snmpd,
<karlp>
familiar enough with tcpdump syntax to give me a command line?
<karlp>
I never remember all the magic
<damex>
sudo tcpdump -n -s0 port 161 and udp
<damex>
oh, no sudo ;p
dangole has joined #openwrt-devel
<Borromini>
:P
<karlp>
added to the ticket, arrives, but never leaves
<karlp>
why do you have -s0? is that because "you've always done that" ?
<dangole>
ynezz: next time please at least revert the offending commit and not a random other commit by me....
<rsalvaterra>
ynezz: See? I told you guys. :P
<rsalvaterra>
I believe the commit is fine… it's just sysupgrade that need to be… smarter…?
Guest88073 is now known as lep-delete
<stintel>
dangole: ujail is too broken to shove it down people's throats
<stintel>
ideally for such changes I would gather a few acks first before pushing
<dangole>
stintel, rsalvaterry: just trying to find out if the right commit has been reverted, because people have been complaining about the procd update and what was reverted is the switch to have ujail installed by default. that's not related to ubus not coming but, but probably the commits just before are.
<dangole>
so my question is: i anyone test-run the revert-commit before applying it?
<damex>
dangole: why did you commit your changes without testing it first?
<dangole>
damex: i did of course test it a lot, for about a week. it has also been sitting in my staging tree for some days.
<rsalvaterra>
dangole: Sure, I'm not blaming ujail at all (even though I personally don't use it). The underlying issue is much older, the fact that /etc/{groups,passwd,shadow} are unconditionally backed-up/restored. If a new user is added, it won't be there after sysupgrade.
<stintel>
haven't followed the actual breakage tbh, but I had to disable ujail for dnsmasq because after some uptime I could no longer restart dnsmasq
<stintel>
and I am blaiming ujail for that
<dangole>
ah ok. i didn't try with restoring configuration. yes, if /etc/passwd and /etc/group are not updated that is a big problem.
<karlp>
maybe ujail got selinux blocked ;)
<stintel>
dangole: sysupgrade and new users/groups being added is a big issue
<stintel>
it's been discussed a few times but never fixed
<dangole>
because that will break quite everything i'm doing right now: moving each service to run as it's own user instead of root.
<dangole>
sure, such change is never convenient for anyway, and i was aware about that before
<rsalvaterra>
Yeah, eggs need to be broken, etc… but sysupgrading from 19 to 20 will be… "fun".
<rsalvaterra>
(Is sysupgrade even supported between major versions?)
<stintel>
if that's what you are doing you should really come up with a solution for that new users missing when sysupgrade
<stintel>
first
<stintel>
rsalvaterra: it is supposed to be
<karlp>
just as well "20" isn't out yet then rsalvaterra ...
<rsalvaterra>
stintel: The problem is knowing how to safely merge the files.
<stintel>
I see people keep advising to not restore the configuration when doing that but I disagree. migrations should be added. if you can't sysupgrade without nuking settings then sysupgrade is completely useless
<karlp>
what's not needed to be supported is "some random point on master" to "some other random point on master"
<dangole>
imho sysupgrade between major versions never worked well, every other attempt to do that broke something for me in the past. downstream projects like libremesh are completely disabling the option to keep config over sysupgrade for that reason.
<rsalvaterra>
karlp: Thank God! :P
<damex>
karlp: snaplen is not really needed but easier to be set 0 when you don't know what to expect
<karlp>
damex: did you read the man page to see what -s0 actually does?
<stintel>
rsalvaterra: that's why I suggested uci-defaults. a package can `id -u someuser || useradd ...` or so
<karlp>
I'm with stintel, if you can't sysuypgrade from one stable release to the next, it's useless.
<stintel>
not saying you should sysupgrade from 12.whatever to 19.07
<stintel>
but from one major release to the next should be supported
<karlp>
agreed.
<stintel>
if the project is not going to do so, I'm going to find another project to run on my devices
<rsalvaterra>
stintel: Come on, don't be so dramatic. It's just a bug. :)
<dangole>
anyway. so in the end the wrong commit was reverted :( because that one could have stayed, it was just the reflex to blame uajil. because it's procd itself which was changed to run ubusd as user ubus (which needs to exist for that to work)
<damex>
karlp: yeah, it is actually defaults to 0 ( 262144 ) as default backward compatibiltiy. Snarf snaplen bytes of data from each packet
<rsalvaterra>
dangole: It's easy to blame the wrong thing. Heck, I blamed the SLOB allocator (which is working fine in Linux 5.4), I'm testing it on a 4/32 device and it seems to save a bit of memory.
<dangole>
ok, i'll just fix that in fstools, so /etc/passwd, /etc/shadow and /etc/group gets merged instead of overwritten...
<stintel>
how are you going to do that ?
<damex>
some awk maybe?
<stintel>
sounds very hackish
<stintel>
I'd be happy to see someone come up with a solution, but please have it reviewed
<stintel>
I would prefer something like I suggested earlier but we don't have useradd by default so meh
<damex>
stintel: can't useradd be added? it is a pretty small binary
<damex>
it is adduser in busybox actually
<grift>
one can also look into a compromise
<grift>
if we can filter syscalls and limit capability access then the power of root is already greately reduced
<grift>
sure its not perfect, but neither is setuid
<grift>
besides do we really need setuid if we have ambient capablities?
<ynezz>
dangole: couldn't you just appear sooner? :) 1.) That commit was suggested, people claimed here, that reverting it fixed the issue 2.) do_page_fault(): sending SIGSEGV to ujail for invalid read access from 00000100f3708c81 3.) I don't remember seeing any prior discussion on the list for such radical change
<ynezz>
dangole: IIRC correctly adding those packages by default is enough to enable ujail
<ynezz>
there is probabably plenty of issues which needs to be ironed out first, I don't think, that it's ready for prime time
<ynezz>
last time I've tried snapshot with procd/ujail under x86_64/qemu it was crashing after 12hours or so due to OOM issues
<ynezz>
didn't have time to debug that yet
<dangole>
yness: yes, and that is the goal and intention (having ujail enabled for dnsmasq, ntpd, umdns and maybe more services, rather than running them with all privileges as root)
<ynezz>
I get it and I support that
<ynezz>
but perhaps we need to do it in less invasive way :)
<ynezz>
like call for testing or such, not enabling it by default
<ynezz>
I had some strange issues with dnsmasq as well (but those happen even without ujail)
<dangole>
ynezz: that's how ujail did not get used in 5+ years since John came up with it
<ynezz>
yeah, true
<dangole>
ynezz: and sure, running everything as root and unrestricted is surely more convenient and flexible.
<ynezz>
it feels just strange, such fundamental changes, yet didn't proposed/discussed on the list
<ynezz>
not that anyone would care, but now we couldn't complain either :)
<dangole>
ynezz: so i understand that people will hate that kind of change. because best case they won't notice and everything still works, maybe it prevents some vulnerabilities we most likely wouldn't know about either way.
<dangole>
ynezz: i see. i felt i've been working on and talking about ujail for a while now, pushed things to my staging tree regularly and did receive quite some feedback from people trying that
<ynezz>
yeah, I know and I value your work
<dangole>
ynezz: but maybe good to reiterate the roadmap evey once in a while after some silence. to me we had agreed to have ujail enabled by default on !SMALL_FLASH for the "next release", but yes, that's more than year ago it has been last debated publicly
<ynezz>
indeed
<dangole>
i'll fix that /etc/{passwd,shadow,group} merger on sysupgrade, so we can go forward with this asap
<ynezz>
I'm sorry, but I don't have much time now to help you with that, but I'm sure, that you've now few testers around
<dangole>
would also be nice to reproduce that segfault
<ynezz>
damex: ^
<ynezz>
AFAIK it was caused by initramfs
<damex>
yeah, all i did is boot to memory (initramfs+kernel)
<dangole>
damex: on x86/64?
<damex>
dangole: mips64
_whitelogger has joined #openwrt-devel
Borromini has quit [Quit: Lost terminal]
Nick_Lowe has joined #openwrt-devel
dangole has joined #openwrt-devel
<dangole>
ynezz, rsalvaterra, stintel: solution for merging /etc/passwd et al after sysupgrade could be as simple as this: https://termbin.com/ap3h (untested, going to test extensively now)
<rsalvaterra>
Looks simple enough, yes.
<dangole>
ie. this keeps lines imports lines /rom/etc/passwd if that users doesn't exist in /etc/passwd at all, same for /etc/group and /etc/shadow
<damex>
dangole: want me to check for something?
<dangole>
damex: lemme pull things together in my staging tree, i guess the segfault is getpwnam not being checked for !NULL
<dangole>
damex: no, that was a first guess, but that's not it. can you start ujail manually with the same parameters using gdb and see which line is indicated for that segfault?
<damex>
gonna take a while to build that + gdb
<damex>
dangole: want me to include anything else?
<dangole>
damex: for now just build as you did so we can tackle that segfault where it appears.
<dangole>
damex: what i do for debugging is rename /sbin/ujail to /sbin/ujail_real and have a shell-wrapper at /sbin/ujail logging the cmdline it was called with and not doing anything. in that way i can then call that exact ujail cmdline with gdb, strace or whatever i like.
muhaha has quit [Quit: Connection closed]
<dangole>
damex: i'd be grateful not having to setup a mips64 build...
<damex>
sure, it is currently building generic octeon + that commit with procd-ujail and procd-seccomp on top
<dangole>
damex: so now replace /sbin/ujail with a simple shell script logging into /tmp/ujail.log what it has been called with
<damex>
dangole: set -x && /sbin/ujail_real ${@}
<damex>
enough?
<damex>
oh logging
<damex>
okay
<dangole>
damex: i'd usually not even call ujail_real in my /sbin/ujail wrapper, just have it log the cmdline, so i can call it manually with gdb
<damex>
dangole: how do i run it again to reproduce?
<damex>
without reboot ofcourse since it is initramfs
<grift>
when someone tests that passwd merge patch , maybe see what happens if there is an entry in existing /etc/passwd: "joe:x:81:81:/var:/bin/false", might not be an issue but might be worth trying
<dangole>
grift: that would be replaced by ubus:x:81:81:... i don't check for overlapping uids/gids as we are managing those in a monolithic way and nobody should ever create a UID<1000 other than those listed in as USERID:= in packages, and those don't overlap.
victhor_ has joined #openwrt-devel
<dangole>
grift: but you are right, it wouldn't even be replaced :( we'd then have two users with uid=81...
<dangole>
grift: no sure if it's worth trying to catch that sort of things, but maybe limiting the merge for uid<1024
<grift>
and what value does ubus use here? USERID:=ubus=81:ubus=81
<grift>
the numerical id or the translated name?
<karlp>
are we _actualyl_ manbaginng uids? we've spoken about it, but I didn't know hwe'd actually done anything about it
victhor has quit [Ping timeout: 256 seconds]
<grift>
otherwise you might end up with ubusd associated with uid joe?
<grift>
but yes looks a bit fragile
heffer has joined #openwrt-devel
<dangole>
grift: hm. we should never have uid>=1000 in /rom/etc/passwd and users should never create uid<1000 having a different name than the one defined as USERID:= by packages.
<grift>
agreed but it will happen
<dangole>
grift: the first convention is already satisfied, the second one should be documented maybe, but it's also kinda covered by POSIX that UID<1000 is "OS managed"
Tusker has quit [Quit: Time wasted on IRC: 9 hours 3 minutes 51 seconds]
<damex>
dangole: so uh, how are you suggest to run ujail again?
<damex>
box is ready and running generic initramf+kernel build from ram
<dangole>
damex: yes, please run `gdb /sbin/ujail` and then in gdb do `run "$@"` with the parameters ujail was called with
<damex>
dangole: i have no idea which parameters it was runing with
<damex>
let's say i add the script in place of binary. how do i reproduce that execution of ujail?
<dangole>
damex: that why i use that shell script in place of /sbin/ujail to log the exact call parameters
<damex>
dangole: sure, i did that. how do i make system execute that?
<dangole>
damex: if your scripts logs into a file, then just look into that file, copy the parameters and paste them into gdb
<dangole>
damex: ie. my /sbin/ujail looks like this: "echo "$@" >> /tmp/ujail.log"
<damex>
sure, but i can not reboot machine to make ujail run again
<damex>
and it does not get to run automatically
<dangole>
damex: /etc/init.d/dnsmasq restart ?
<damex>
oh, okay
<dangole>
damex: i guess, as that'd be the only service running with ujail by default for now
<dangole>
damex: umdns :)
Aleksey has joined #openwrt-devel
<Aleksey>
Hello!
<dangole>
grift: looking into that uid overlap issue, there is no good solution. because what we do then, if the user already got another username set for that uid in /etc/passwd? i can't even imagine a meaningful error-patch which would not break stuff in that moment...
<dangole>
*error-path
hsp has quit [Read error: Connection reset by peer]
<damex>
dangole: sent output to pm, does not make sense
hsp has joined #openwrt-devel
dangole has quit [Remote host closed the connection]
<grift>
dangole yes thats a pickle, i guess using useradd would address this but yes i know thats expensive. also note that obviously generic distributions have dealt with this as well
<grift>
i was just laying this on the table for consideration though, this isnt really my cup of tea
<damex>
grift: adduser != useradd and is available on busybox and is very cheap
<karlp>
maybe.... we stop using numeric uids?
<grift>
right adduser is a wrapper around useradd
<damex>
oh... really? didn't knew that :(
<grift>
so yes i meant consider using useradd
<grift>
in debian its a wrapper atleast
<grift>
adds bells and whistles such as finger etc
<grift>
debian also has a adduser that is basically a wrapper (superset) around/of useradd
<damex>
grift: it could be enalbed though openwrt build system. to test - choose busybox -> customize -> loginutils -> its there
<damex>
> bool "adduser (15 kb)"
<damex>
is it small enough?
<grift>
yes ill be honest, i kind of in a way like the idea of openwrt being a single user system by default
Grommish_ is now known as Grommish
<grift>
but i think of it in a selinux scenario, and i admit that in a non-selinux scenario some extra security is needed as well
dangole has quit [Remote host closed the connection]
<grift>
so eventhough its "just" 15KiB is kind of sets a precendent
<grift>
i would probably add a user if useradd/adduser what available on my router quicker then when i would have to do it manually or if i would have to install the util first
<damex>
yeah, it has to be available out of box everywhere
<damex>
it is a part of busybox and i don't think you can ship it separately
feriman has quit [Ping timeout: 260 seconds]
<grift>
... not on a single user system i guess
<damex>
oh
<grift>
well thats just my humble view
<grift>
i am just saying that i kind of understand the decision to not have it, but this changes that and that then brings up a different question
<grift>
which way to go
<damex>
k.i.s.s. way
<grift>
agreed, so then i guess its a matter of defining that (not just when it comes to uid's but also about what we intend to address by adding uids)
<grift>
maybe theres a simpler way to achieve something similar?
Grommish has quit [Read error: Connection reset by peer]
<grift>
decision kind of has already been made though since atleast dnsmasq has its own uid
<grift>
so yes provided that adduser solves the issue i guess that should be considered
Grommish has joined #openwrt-devel
<grift>
because yes i would argue that if youre going to manage users then you better do it in a robust way
<damex>
if we get selinux forced on people - openwrt will lose users
<damex>
or maintainers
<grift>
yes but thats a big if
<grift>
but yes (barring and defensec in depth) that would simplify things
<grift>
defense*
dangole has joined #openwrt-devel
<grift>
o i misunderstood
<grift>
i think youre assuming there
<grift>
but anyways thats not going to happen anyway most likely so no reason to worry about that
<damex>
grift: that is from my personal experience integrating selinux/grsec/etc
<grift>
do you have android phone?
<damex>
no, not anymore
<grift>
more then a billion people run selinux
<grift>
its just a matter of implementing it properly
<damex>
you need to be able to describe rules in a human readable and understandable manner
<grift>
no
<damex>
and need to force it down to everyone
<damex>
if it is not - lots of stuff will be selinux-incompatible and most likely won't work
<damex>
grift: why human factor is not a factor here?
<damex>
who will write rules?
<grift>
vendor
<dangole>
grift, ynezz, rsalvaterra: i think i found an elegant and sufficient hack for adding missing lines to /etc/passwd, /etc/group and /etc/shadow:
<grift>
last thing you want is have "users" address security
<dangole>
damex: if we decide to have that anyway, i'm all for having it
<damex>
dangole: i think people have missunderstanding what you mean when someone say 'adduser' tool. there is many alternatives and that one have to come from busybox to satisfy embedded requirements
feriman has joined #openwrt-devel
<dangole>
damex: if it's just for solving that sysupgrade /etc/passwd problem then it'd be like adding 15kB binary instead of 300b shell to solve some rare/unsupported corner cases
<damex>
grift: yes, so the problem be on maintainer shoulders and people maintaining opensource do not want extra burden. generally
<grift>
do you think that stuff like leveraging seccomp filters in a meaningful way does not require maintenance?
<damex>
it does. all of that stuff require maintenance
<grift>
exactly
Aleksey has quit [Remote host closed the connection]
<damex>
maybe we will get a sudo at some point ;D
<damex>
and properly managed users with separate ssh keys and etc... and maybe integration with ldap/radius ;p
<grift>
anyway i was just throwing that uid scenario out for consideration , i have no strong feeling on it. but just nothing that theres murphies law
<grift>
if it can happen it will happen
<grift>
thats exactly what i meant with precedent damex
<grift>
having users implies useradd, and then next someone will make the case of sudo by default
valku has joined #openwrt-devel
<grift>
where does the buck stop?
<damex>
actually i would be glad if we get a users and radius/ldap support. i will be able to throw openwrt in place of vyos installs (that does it poorly) for NE that understand no thing to manage firewalls
<damex>
but that is kinda offtopic ;p
<damex>
grift: well, it does not stop unless there is a line drawn... somewhere
<rsalvaterra>
damex: I actually configured an OpenWrt system with "proper users" and sudo, years ago. Not really worth it.
<damex>
dangole: sure, then that binary have to become of a core
<damex>
rsalvaterra: there is lots of things to address (luci and such) before it becomes usable in a sane manner
<damex>
rsalvaterra: yeah, agree, not really worth it
<rsalvaterra>
damex: That was one of the reasons I just gave up on LuCI at the time. :)
<grift>
so maybe start by leveraging capabilities first and go from there?
<rsalvaterra>
Nowadays, I don't care. I do everything though the terminal, it's so much more convenient.
<rsalvaterra>
*through
valku has quit [Quit: valku]
<damex>
well, i am using shell to manage openwrt install but luci is there to just show representation of something like wireless and such when you're lazy and just want a fancy page ;p
<damex>
with ansible becoming a defacto a standard at managing such things - not every single openwrt can be managed due to lack of python :(
<rsalvaterra>
Eek! Python?! Good heavens…!
valku has joined #openwrt-devel
<grift>
hahah thats exactly my first thought
<grift>
python on my router, no thanks
<damex>
blocktrron: any suggestions on how can i generate exactly the same of_platdata as you did for nanopi so i could get librecomputer renegade merged?
<jow>
sigh... a few days away and master is broken big time
<karlp>
when the cat's away.... ;)
<jow>
seriously, it starts to annoy me
<jow>
who thought that it is a great idea to simply relocate the ubus socket path?
<jow>
and of course anything that might be affected by that was neglected
<jow>
can't you at least put *some* effort into this before you fuck around with that stuff
<dangole>
jow: i grepped through packages and core and didn't see any direct mention of that patch
<jow>
rpcd seems broken
<jow>
uhttpd too
<karlp>
grep won't find defaults, only explicits
<jow>
and grep - wtf
<jow>
boot that crap, and open the fricking ui in a browser at least once
<dangole>
jow: i did boot that for quite some days, and so were other people reviewing it on my staging tree
<dangole>
jow: probably nobody did sysupgrade and kept config, so that was fixed now (missing entries in overwritten /etc/passwd)
<dangole>
still sorry for that mess, of course
<grift>
where people work mistakes are made, in fedora theres 100 developers making many changes in rawhide stuff is always broken, but innovation has to start somewhere and thats what rawhide/master is for ?
<jow>
fine, by that standard I'll push my half completed crap as well now
<jow>
and apaprently we do not care about backwards compatibility either naymore, so lets throw some breaking changes into the mix
<grift>
not saying things should be tested to the best of your ability. just saying mistakes are made
<grift>
s/should/shouldnt/
dangole has quit [Remote host closed the connection]
esters has left #openwrt-devel [#openwrt-devel]
<grift>
.. but yes after that commit was made in the staging tree i was waiting for dangole to show up here so that i could vent my concerns about it
<dangole>
jow: i've added migration for rpcd and uhttpd, if you spot any more, let me know
<dangole>
jow: please note that i
<dangole>
'm here and do take care of fallout
<dangole>
grift: i'm reading the chat logs even when i'm not connected on the channel
valku has quit [Read error: Connection reset by peer]
<dangole>
grift: mentioning my name will make me see it a few hours later
<grift>
dangole ok good to know
valku has joined #openwrt-devel
<grift>
dangole so about the setuid/ntpd thing, no that wont solve the selinux transition issue
<grift>
you can compare selinux domain transition to setting the setuid bit on a file
<grift>
so you can reason like this:
<dangole>
grift: what was your concern with that ubus socket path change? why could it get ugly (in terms of SELinux)?
<grift>
would chowning busybox ntpd and setting the setuid bit solve the uid issue?
<grift>
if no then it also would solve the selinux domai ntransition issue
<grift>
s/would/wouldnt
<grift>
well the path isnt so much an selinux issue the question is how will it be created i guess
<grift>
but that commit comment wasnt so much about selinux, it was just a comment that "things could get ugly" in general
<dangole>
grift: procd mkdirs it before starting ubus and chowns it
<grift>
because its ubus and messing with that in anyway is kind of tricky
<grift>
k
<grift>
anyway dont worry about the selinux aspect
feriman has quit [Quit: WeeChat 2.9]
<grift>
thats secundary
<grift>
but about ntpd domain transition
<grift>
heres two bookmarks that demonstrate how to do that programmatically, and if that doesnt answer any question that those bookmarks should lead to more examples:
Ycarus has quit [Read error: Connection reset by peer]
Ycarus has joined #openwrt-devel
muhaha has joined #openwrt-devel
eduardas has quit [Quit: Konversation terminated!]
decke has quit [Quit: Leaving.]
adrianschmutzler has joined #openwrt-devel
MarioH has quit [Ping timeout: 260 seconds]
Darkmatter66 has joined #openwrt-devel
Darkmatter66_ has quit [Ping timeout: 256 seconds]
MarioH has joined #openwrt-devel
hbug__ has quit [Remote host closed the connection]
hbug__ has joined #openwrt-devel
<damex>
what if i want to introduce octeon3 subtarget and device in there - do i introduce octeon3 first and then add device or do both at the same time?
<adrianschmutzler>
a subtarget without a device won't make much sense
<adrianschmutzler>
The question is rather whether a subtarget will be justified
<Nick_Lowe>
Is a wide patch likely to be accepted for this?
<adrianschmutzler>
Nick_Lowe: probably not, and if, not fast
<adrianschmutzler>
so, you will get rebase-hell
<adrianschmutzler>
there are a few smaller patches like this in the mailing list patchwork.
<stintel>
I'm hesitant. I've seen breakage due to people fixing shellcheck warnings. easier to review package by package basis
<adrianschmutzler>
I think the main challenge will be to put the changes into reasonable blocks.
<stintel>
also if there is breakage, reverting a big tree-wide patch is ... meh
<adrianschmutzler>
fact
<adrianschmutzler>
on the other hand, the problem with the per-package approach is that you then have to mix different types of fixes
<adrianschmutzler>
I frequently had that problem with Rosen's patches, where I was sure about two changes but hesitant on two other ones in the same patch
<stintel>
well that's just wrong to accept. bump a package + fix shellcheck in its scripts are 2 commits
<stintel>
whoever accepts those should stop doing that in the first place
<stintel>
they can go in 1 series, but it should be 2 different commits so it allows proper bisecting
<adrianschmutzler>
I was referring to different "types" of shellcheck recommendations
<adrianschmutzler>
Rosen typically splits that up properly, but sometimes there still are cases like that
am0rphis has quit [Ping timeout: 240 seconds]
<damex>
adrianschmutzler: i think it will be justified. there is octeon3 devices (7xxx octeons) that have FPU (hardfp) and that benefit from march=octeon3.
<damex>
currently 'octeon' target is soft-float
<adrianschmutzler>
damex: but mere speed improvement (unless really massive) typically is no reason to have the overhead of a separate branch
<dangole>
stintel, rsalvaterra, adrianschmutzler: in israel they made contracts with private people over more than 30 days un-enforcable/illegal, sim-lock was banned and infrastructure-owning companies (ie. traditionally Bezeq for phone copper pairs and HOT for tv coaxial copper) cannot act be ISPs...
<dangole>
seems like some of that law was broken again recently though
<dangole>
and yes, EU should regulate telco contracts like financial services (which is what they are in the end)
dangole has quit [Remote host closed the connection]
<grift>
lets just say that there is a lot of room for improvement in that industry (to say the least)
<blogic>
board holds the channel, tx power, rrsi threh type settings
<blogic>
*thresh
aszeszo has quit [Quit: aszeszo]
<aparcar[m]>
so when the CDN goes down you can't configure your local routers anymore?
<aparcar[m]>
anyway sounds rad. Sure I'll docker it, in fact someone just offered me offered me money to port a docker runtime to OpenWrt, strange huh?
Ycarus has quit [Quit: Ycarus]
Nick_Lowe has joined #openwrt-devel
linzst has quit [Quit: Leaving]
<ynezz>
cp cgroups docker-runtime
pstef has joined #openwrt-devel
Nick_Lowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<aparcar[m]>
ynezz: pssst I need this new surf borad
<damex>
i can't bring subtarget to a target that had no subtargets before, is that right? i need to move target's boards to some subtarget... right?
<damex>
something like target -> (subtarget with target old boards) + (subtarget with new boards that is different from old ones)
<adrianschmutzler>
you can ignore all the split base-files stuff for now.
Borromini has joined #openwrt-devel
<damex>
adrianschmutzler: thanks, checking that mvebu PR :)
<adrianschmutzler>
damex: it's also the most recent case where a subtarget was not accepted as the benefit was not "sufficient"
Darkmatter66 has quit [Quit: ZNC 1.7.5 - https://znc.in]
<damex>
been thinking... maybe just add device to existing target first?
<adrianschmutzler>
if the device works there, too, it might at least get the device merged
<adrianschmutzler>
be aware that octeon is not really crowded with reviewer and committers; making it easy is even more imperative there than usual
Howaner has joined #openwrt-devel
RealHowaner has joined #openwrt-devel
RealHowaner has quit [Client Quit]
Howaner has quit [Client Quit]
Howaner has joined #openwrt-devel
<Howaner>
Hey, does anyone know the error "Initramfs unpacking failed: invalid magic at start of compressed archive"? I updated openwrt to the latest master (linux 4.19 instead of 4.16) and now initramfs boot is broken on my device
<Howaner>
*(old: linux 4.14, new: linux 4.19)
Nick_Lowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Slimey has quit [Remote host closed the connection]
Slimey has joined #openwrt-devel
Borromini has quit [Quit: Lost terminal]
black_ant has quit [Ping timeout: 260 seconds]
kubrickdave_ has quit [Read error: Connection reset by peer]
kubrickdave has joined #openwrt-devel
kubrickdave has quit [Read error: Connection reset by peer]
kubrickdave has joined #openwrt-devel
kubrickdave has quit [Read error: Connection reset by peer]
adrianschmutzler has quit [Quit: ~ Trillian - www.trillian.im ~]
<blogic>
aparcar[m]: the cdn will run in a mdu deployment on a cascaded ucpe
<karlp>
bingo!
<blogic>
in a private deployment it'll run on your locall trusted hosting provider
<blogic>
or even on a local router
poljar1 has joined #openwrt-devel
<blogic>
karlp: what ?
<blogic>
you can take the piss but I am actually trying to fix a problem in sane and scalable way here
<karlp>
blogic: acronym soup bingo
<blogic>
normally commercial wifi is run against a aws cloud
<karlp>
it's nice to see the very first mention of it when you're already well into the details and concrete implementations
poljar has quit [Ping timeout: 265 seconds]
<blogic>
so rather than doing so, it makes sense to deploy a ucpe (univerals customer premisses equipment) device to cascahe the controller for mdu (multi dwelling units) on site such that even if a netplit happens, the local insatnce is still operational
ivanich has joined #openwrt-devel
<blogic>
basically meaning, lets move logic away from the cloud and let it happen on sight
<blogic>
and then let the ucpe handle syn-up to the evil cloud as an option if there really is a requirement ot even do so
<blogic>
and the ucpe should really be able to handle de centralized load balancing and band sterring locally without the need for some crappy machine learning cloud techno hipster BS
<blogic>
ideally you wont even need a ucpe
<blogic>
but be patronizing all you want
<blogic>
typos, hate small android keyboards when fast typing
ivanich has quit [Quit: Konversation terminated!]
Skeleswant has quit [Quit: Gone to IKEA]
rsalvaterra has quit [Quit: Leaving.]
dangole has joined #openwrt-devel
<dangole>
ping damex
<dangole>
so i found a way to work-around the segfault in ujail on mips64
<dangole>
so this triggers when calling elf_load_deps("/lib/ld-musl-mips64-sf.so.1", ...), right *after* elf64_scan_dynamic successfully run and found out that ld.so doesn't have any needed dynamic library dependencies... then it mysteriously gets called again for no reason
<dangole>
i'll retry with a more recent GCC and see what happens...