telmich | timeless: in the best case your ISP should offer IPv6, that is absolutely correct. The VPN offered by ungleich is really for the cases when you cannot get IPv6 otherwise reliable | 14:12 |
---|---|---|
telmich | timeless: I have it for instance on all notebooks/phones, because mobile phone providers don't give you IPv6 in Switzerland (or at least salt) | 14:12 |
fsmithred | why do I have firefox cookies from places that I last visited in 2016??? | 15:02 |
fsmithred | I've cleared my cookies hundreds or thousands of times since then | 15:02 |
fsmithred | and they no longer go away when I close firefox | 15:03 |
MinceR | maybe the setting to remove cookies on exit was among the many settings they removed | 15:47 |
MinceR | like the settings to disable javascript or prevent javascript from hijacking right clicks | 15:48 |
fsmithred | it's very weird. Most of the time it appears that the cookies are all gone, and this time when I closed the browser, some of the cookies went away, but a handful remained, and a few of them were very old. | 15:50 |
cosurgi | I should someday switch from chromium fo firefox. However this is how I dealt with chromium problems: I added ~/.config/chromium/Default/Bookmarks to git dotfiles. Every couple weeks I rm -rf ~/.config/chromium/, also I have set immutability attribute on file ~/.config/chromium/Default/Preferences, like this: | 16:01 |
cosurgi | $ lsattr ~/.config/chromium/Default/Preferences | 16:01 |
cosurgi | ----i---------e---- /home/praca/.config/chromium/Default/Preferences | 16:01 |
cosurgi | with commant sudo chattr +i .config/chromium/Default/Bookmarks/Preferences | 16:01 |
cosurgi | And that's it. Chromium is totally wiped out, and doesn't even notice. While I keep using it with exactly the same config all the time. | 16:02 |
cosurgi | Ah, before wiping it out I copy files Current Session,Current Tabs,Last Session,Last Tabs. So that restaring it after the wipe has exactly the same window sopened. | 16:03 |
xrogaan | firefox 60.6.3 is finally available from ascii-updates; took only one week :P | 19:30 |
xrogaan | MinceR: for firefox you can disable javascript through the webdev thing https://files.catbox.moe/6lsexp.png | 19:33 |
MinceR | i know | 19:35 |
MinceR | but they used to have a setting for it in preferences | 19:35 |
xrogaan | For ease of use, I have this https://addons.mozilla.org/en-US/firefox/addon/javascript-toggler/ | 19:44 |
xrogaan | I just noticed that if I block all access to the internet but localhost, chromium still can access google. | 20:16 |
xrogaan | but nothing else | 20:16 |
xrogaan | my iptables rules http://dpaste.com/0XR3CD7 | 20:18 |
gnarface | i don't think changing those settings would kill off existing connections | 20:20 |
gnarface | try just restarting chromium | 20:20 |
xrogaan | i start chromium under the "no-internet" group | 20:20 |
xrogaan | sg no-internet -c 'chromium' | 20:21 |
xrogaan | so there is no connection made at all | 20:21 |
xrogaan | chromium cannot reach anything else, just google | 20:21 |
xrogaan | Can I setup a rule to deny an interface? | 20:22 |
DocScrutinizer05 | my ISP doesn't really offer decent IPv4 :-/ | 20:27 |
DocScrutinizer05 | I can switch the damn modemrouter to bridgedmode which gives me a semi-working IPv4 on their damn cgNAT hey use to route their "4over6" cable access to the real world. But then a) my cable TV blows chunks, and b) seems their cgNAT IP range is on several RBL now so fo example I only get "page doesn'T exist" on AliExpress no matter which URL | 20:30 |
gnarface | xrogaan: set everything to DROP, try that | 20:32 |
DocScrutinizer05 | hi timeless! | 20:32 |
gnarface | xrogaan: try it like this, just as a test: http://paste.debian.net/1082050/ | 20:38 |
Wonka | DocScrutinizer05: funny, aliexpress is on akamai - is akamai not fully DS already? why would they? | 20:43 |
xrogaan | gnarface: I should have said it before, but this works: `DROP all -- anywhere anywhere owner GID match no-internet` | 20:44 |
xrogaan | just the drop all anywhere if the gid matches | 20:44 |
xrogaan | chromium manages to get to the google servers if localhost isn't blocked | 20:45 |
MinceR | does it actually make a connection or does it just render a page? | 20:45 |
xrogaan | i can search the web | 20:46 |
xrogaan | and I can watch youtube video | 20:49 |
MinceR | sounds like the network blocking doesn't work | 20:49 |
MinceR | maybe it's using a different protocol, like SPDY? | 20:49 |
xrogaan | listens to 224.0.0.251:5353 in udp | 20:49 |
xrogaan | I don't filter on protocol, I just drop everything | 20:53 |
xrogaan | apparently, -owner only works for OUTPUT and POSTROUTING. I can't have that. | 21:04 |
MinceR | have you tried running chromium in a namespace that had no network access instead? | 21:04 |
xrogaan | how? | 21:09 |
xrogaan | what do you mean by namespace? | 21:09 |
MinceR | the linux kernel feature | 21:10 |
MinceR | i can't find the command line to do it before, though | 21:10 |
xrogaan | what a pain in the ass | 21:33 |
rebag | hey. How to have the same *same* environment with #root user and crontab root user please ? | 21:57 |
xrogaan | crontab uses the system environment | 22:00 |
xrogaan | check /etc/default/cron and /etc/init.d/cron | 22:01 |
rebag | yes | 22:01 |
rebag | the software that need cron (bup), fails because of the differences between the 2 environments ... | 22:01 |
xrogaan | no, really, read /etc/default/cron | 22:02 |
xrogaan | maybe I can highlight the relevant part: `This has no effect on tasks running under cron; their environment can only be changed via PAM or from within the crontab; see crontab(5).' | 22:02 |
rebag | yes and : READ_ENV="yes" | 22:03 |
xrogaan | maybe I can **really** highlight the relevant part: `This has no effect on tasks running under cron; their environment can only be changed via PAM or from within the crontab; see crontab(5).' | 22:03 |
xrogaan | I don't know bup though, so I might be wrong. | 22:04 |
rebag | heh yes ok. But I dunno pam, i understand PAM is the onlyway to get the same env as root isn't it ? | 22:05 |
gnarface | xrogaan: uh... you allowed localhost/8 to pass through, right? | 22:06 |
rebag | "or within the corntab" | 22:06 |
rebag | crontab | 22:06 |
gnarface | xrogaan: i'm not sure you want to allow all those ip's through. i'm not sure they're actually all localhost | 22:06 |
xrogaan | gnarface: I don't understand | 22:07 |
gnarface | well, i might be wrong here, but the fundamental thing i'm worried about is that localhost is 127.0.0.1, and you're actually passing everything from 127.0.0.0 to 127.255.255.255 | 22:08 |
gnarface | and i've never seen that before | 22:08 |
gnarface | that's all | 22:08 |
gnarface | also i'm not sure you're blocking ipv6 at all | 22:08 |
rebag | really I don't understand what I have to do. I have this problem for months now I tried various things including adding source in the crontab. I dunno PAM at all. Then any help appreciated | 22:08 |
xrogaan | gnarface: I don't know what you are talking about. I drop everything if the gid matches the rule. | 22:09 |
xrogaan | rebag: my guess is ask the bup people | 22:09 |
rebag | we have tried in the bup chan to figure out which variables were missing, without success :( | 22:09 |
gnarface | xrogaan: eh, nevermind. you know what? just put google's ips in your /etc/hosts file and point them back to localhost | 22:09 |
rebag | but it's asolutely shure that it's related to the cron env because with the root env all fine | 22:10 |
xrogaan | gnarface: what do I not catch with the "anything" rule? | 22:11 |
xrogaan | any protocol, anywhere except if the destination is local. | 22:12 |
gnarface | xrogaan: well you said it blocks everything correctly unless you pass localhost traffic, right? | 22:13 |
gnarface | my hypothesis is that you've made a mistake there and that's how its sneaking out | 22:14 |
xrogaan | `iptables -A OUTPUT -m owner --gid-owner no-internet -o lo -j ACCEPT' | 22:14 |
gnarface | but it's not beyond the realm of possibility that chromium is doing something sneaky | 22:14 |
xrogaan | and then: `iptables -A OUTPUT -m owner --gid-owner no-internet -j DROP' | 22:14 |
xrogaan | well, yeah, because chromium *doesn't* have access to the internet, just to google services. | 22:15 |
xrogaan | which is the internet, but apparently not from google's point of view. | 22:15 |
xrogaan | something something chromebook, something something eating data. | 22:16 |
gnarface | so, iptables has INPUT, FORWARD, OUTPUT, PREROUTING, POSTROUTING, MANGLE, and ... maybe some others. if you let it through on any of those, it can sometimes use pre/postrouting or mangle to sneak it through a crack in the armor | 22:16 |
gnarface | i'm foggy on the specifics, and i think they're crap | 22:17 |
gnarface | and i largely suspect this is a common view, because it's already being replaced (again) | 22:17 |
gnarface | so you gotta figure out what it's doing with the packets on a lower level, or you gotta just plug all the holes more explicitly | 22:18 |
gnarface | i don't think there's anything to say that once you've allowed it to access localhost it can't mangle the packets to get them out and back even if "input" and "output" are being dropped if you don't also drop "forward" "prerouting" and "postrouting" and "mangle" ... understand? | 22:18 |
gnarface | so it really might be easier to just block their traffic by ip explicitly, or use the hosts file override if it's doing it by DNS | 22:19 |
gnarface | also... don't forget about ipv6, i'm not sure you've even touched the ipv6 traffic, and chromium might be smart enough to try both ipv4 and ipv6 | 22:21 |
gnarface | if it's actually generating traffic under some other uid/gid than what you're running it as... that would be an extremely dirty trick, but not beyond the realm of possibility | 22:22 |
xrogaan | I understand they can do sneaky stuff, yeah, but I can't match by owner on other hooks than POSTROUTING and OUTPUT. | 22:22 |
gnarface | i'm sorry this is not as specific of information as you want, i'm just trying to outline how many blind spots there are here in your setup | 22:23 |
gnarface | personally i prefer BSD for this part | 22:23 |
gnarface | packetfilter is no less complex, but makes a lot more sense in the end | 22:24 |
gnarface | i think there is an implementation for linux these days. i haven't tried it, but it might be worth it for you | 22:24 |
xrogaan | oh, right, another cli for ipv6 | 22:24 |
xrogaan | I might be that dumb | 22:25 |
gnarface | my hosts file here calls the ipv6 localhost "ip6-localhost", it's distinct from the regular ipv4 localhost. that could also be the culprit, yes | 22:25 |
gnarface | or something related to that | 22:26 |
xrogaan | Yeah, so, for some reason the iptables rule to drop everything based on owner works. If I suddenly allow localhost, chromium has access to google services. But if I then apply the same rule with ip6tables (drop anything based on owner, without the localhost exception), chromium is stuck yet again. | 22:27 |
xrogaan | My question is: "Why?!" | 22:28 |
gnarface | seems like expected behavior in that case | 22:29 |
gnarface | chromium tries ipv4 first then falls back on ipv6 so you have to block them both | 22:29 |
gnarface | doesn't that seem logical? | 22:29 |
gnarface | you should be happy it doesn't try to establish a new network connection to your neighbor's wifi when ipv6 fails, and then start trying ad-hoc routes through nearby bluetooth devices | 22:30 |
xrogaan | Well, I had the DROP rule for everything for a while, but without anything related to ipv6 and chromium never could reach google | 22:30 |
gnarface | oh, hmm | 22:30 |
xrogaan | Today I setup the exception, and suddenly chromium could reach google but nothing else | 22:30 |
gnarface | something a little weird there maybe still | 22:30 |
gnarface | if you do BLOCK instead of DROP does it change anything? | 22:31 |
gnarface | DROP won't bounce the packets, it will just pretend it didn't get them. if you BLOCK instead, the IP stack gets the packets returned as errors | 22:31 |
gnarface | that might trigger different behavior | 22:31 |
xrogaan | How do I do that? -j BLOCK? | 22:34 |
gnarface | yea. while you're testing this, you should run some tcpdumps on all these interfaces, that will tell you exactly where the packets are going, and what ip addreses they're going to | 22:34 |
xrogaan | -j REJECT probably | 22:34 |
gnarface | oh, maybe | 22:35 |
gnarface | though, as i consult the man page, it says it is RETURN | 22:35 |
xrogaan | there are 3 states only: accepted, dropped and rejected | 22:36 |
gnarface | nevermind, RETURN looks like something different | 22:36 |
gnarface | though there's very little information about it on the man page | 22:36 |
xrogaan | so this is working: http://dpaste.com/34MREA4 | 22:38 |
xrogaan | without the last line, chromium has access to the google space. With the first line alone chromium doesn't reach the google space. | 22:38 |
xrogaan | (just to be clear) | 22:38 |
xrogaan | err sorry | 22:38 |
xrogaan | with the second line alone* | 22:38 |
xrogaan | brb coffee | 22:39 |
xrogaan | rebag: bup seems to need specific things, I don't know the software so I can't help you. You will have a better support with the software authors. | 22:44 |
systemdlete | Is setting /proc/sys/net/ipv4/ip_forward to 1 sufficient to make ip forwarding work? I am having a problem on a different system, but maybe devuan runs into this also? | 23:04 |
systemdlete | I can't find an answer by googling. There are smart and HELPFUL :) people here, so... | 23:04 |
systemdlete | I have this working on my CentOS system, and I am currently working on hyperbola (the problem system atm) and shortly, devuan ascii. | 23:05 |
systemdlete | I have 2 physical interfaces, which I want to allow to forward packets to a virtualbox interface | 23:06 |
systemdlete | This exact same config (sans anything I forgot to do, obviously) on CentOS and it works. | 23:06 |
systemdlete | istm, all I did was echo 1 > /proc/sys/net/ipv4/ip_forward and voila! it worked. | 23:07 |
systemdlete | Trying this on devuan will be instructive, to say the least... | 23:07 |
systemdlete | (that's CentOS 6.10, btw, the last of the Mohicans...) | 23:07 |
xrogaan | systemdlete: sysctl seems to be used to do those thingy | 23:16 |
xrogaan | or in /etc/sysctl.conf | 23:17 |
systemdlete | true, but that's just to ensure that the setting is saved across reboots. I see that using sysctl to do this is reflected in the contents of the /proc file | 23:17 |
systemdlete | Yes, sysctl.conf is where sysctl will get its persistence data | 23:17 |
systemdlete | I tried it all different ways. No love | 23:18 |
systemdlete | xrogaan, keep in mind this is hyperbola, not devuan, but that shouldn't make any difference. | 23:18 |
xrogaan | well, I don't know who hyperbola is | 23:19 |
gnarface | /proc should be the same | 23:19 |
gnarface | more or less | 23:19 |
systemdlete | They are an arch distro, but they have removed systemd and they are going to a fixed-release approach based on "stable" snapshots of arch | 23:19 |
gnarface | if you have a custom kernel you might have omitted ip forwarding inadvertently though... | 23:20 |
systemdlete | gnarface: hi, and yes, I agree. | 23:20 |
xrogaan | why no artix linux? | 23:20 |
systemdlete | no custom kernel | 23:20 |
systemdlete | I have artix linux also, but I am seeking a fixed release (LTS) which at this point is only alpine, devuan, hyperbola. | 23:21 |
xrogaan | also, you might want to ask the hyperbola people | 23:21 |
systemdlete | Alpine would be great for xen, but I also need virtualbox | 23:21 |
systemdlete | I've queried them, but because they are a small community, and rather tight, it can be hard to get help. | 23:21 |
systemdlete | And I am not even sure I have a bug. More likeyly something I overlooked I think | 23:22 |
systemdlete | these linux kernels are more or less the same, or should be | 23:22 |
gnarface | are you also using ipv6? is this a virtualized guest of some sort? | 23:23 |
systemdlete | I'm thinking I might move on to installing and configuring devuan for this, and returning to hyperbola later. | 23:23 |
systemdlete | gnarface: ipv6 does seem to be enabled on hyperbola, but I did nothing to effect that. No, not a VM. The only VM is one of the interfaces, as I stated above. But that should not matter. | 23:24 |
systemdlete | gnarface: The only thing I am wondering is that the VM is configured for a paravirtualized interface. If there is a problem with the driver on the host (hyperbola) side, then maybe there is an issue. But,again, all I have done is made the same VMs available on hyperbola as I had on CentOS. There should, in theory, be no difference. | 23:25 |
KatolaZ | systemdlete: echo 1> /proc/... and sysctl have the same effect | 23:26 |
systemdlete | Yes, KatolaZ. Exactly. | 23:26 |
systemdlete | The point is, even though the /proc/... device is set to 1, still packets do not forward. | 23:27 |
KatolaZ | systemdlete: is that ipv4 forward of ipv6 forward? | 23:27 |
systemdlete | Also, I am starting to see DUPs when I ping 8.8.8.8 from hyperbola (local Internet does work through the virtual interface, just not other machines on the LAN) | 23:28 |
KatolaZ | systemdlete: you have a messed-up routing table | 23:28 |
systemdlete | ipv4 forward. There is no similar ipv6 device, but there is /proc/sys/net/ipv6/all/ip_forward | 23:28 |
KatolaZ | most probably | 23:28 |
KatolaZ | that's why I was asking systemdlete | 23:29 |
systemdlete | Maybe. But it really is pretty simple. And almost identical to the one on CentOS | 23:29 |
KatolaZ | for ipv6 the procfiles are arranged differently | 23:29 |
systemdlete | yes, I noticed! | 23:29 |
KatolaZ | systemdlete: almost identical is not identical :P | 23:29 |
KatolaZ | please past your ruoting table | 23:29 |
KatolaZ | ~paste | 23:29 |
KatolaZ | but not here, or the bot will ban you | 23:30 |
systemdlete | different names for the interfaces. eth? on CentOS, enp?s? on hyperbola | 23:30 |
KatolaZ | o_O | 23:30 |
KatolaZ | systemdlete: I thought you were talking of a devuan install | 23:30 |
systemdlete | https://pastebin.com/fBHkru4j | 23:31 |
systemdlete | (no, I did mention early on, see above) | 23:31 |
systemdlete | but as gnarface said, it should be the same | 23:31 |
systemdlete | kernel is 4.9.155 | 23:31 |
KatolaZ | are you sure your vbox config is all right? | 23:32 |
KatolaZ | (meaning, it allows network routing?) | 23:32 |
systemdlete | Yes, because (1) the VM is the same as the one used on CentOS (shared drive) and (2) I am on IRC with you via this very VM | 23:33 |
gnarface | i wonder if it could be some module that just needs to be manually loaded... | 23:34 |
systemdlete | if vbox were not configured properly it would not have worked under CentOS and I'd not be chatting with you here | 23:34 |
systemdlete | gnarface: I thought of that. I did a sweep of everything under /lib/modules and found nothing looking like ip_forward or similar | 23:35 |
systemdlete | see, I really did my homework before coming here to ask. | 23:35 |
gnarface | just making sure | 23:36 |
systemdlete | np. and thanks for asking | 23:36 |
systemdlete | hmmm. Just wondering. Is there a way to easily disable ipv6? | 23:38 |
systemdlete | Just to test, get some data points... | 23:38 |
systemdlete | I don't think I have much ipv6 going on on CentOS. For one thing, the kernel is old, and I think there were some issues with ipv6 on 2.6.32 or so | 23:39 |
fsmithred | there is a way to do that, but I don't remember the exact words | 23:39 |
systemdlete | (hi fsmithred) | 23:39 |
fsmithred | hi | 23:40 |
systemdlete | https://www.techrepublic.com/article/how-to-disable-ipv6-on-linux/ | 23:40 |
fsmithred | search for 'blacklist ipv6' at forums.debian.net and you'll find the answer a bunch of times | 23:40 |
fsmithred | yeah, do it the debian way | 23:41 |
fsmithred | in /etc/sysctl.conf | 23:41 |
systemdlete | done | 23:41 |
systemdlete | now lets see... | 23:42 |
systemdlete | nope. still nothing. | 23:43 |
systemdlete | well, I guess it is time to stop wasting time -- esp the time of the valiant heroes on #devuan -- | 23:43 |
systemdlete | and move on to configuring my devuan domain (same hardware, different partition) | 23:44 |
Evilham | systemdlete: sysctl net.ipv6.conf.all.disable_ipv6 1 | 23:44 |
systemdlete | Evilham: thanks. Got it. Did it. Got the t-shirt. But still no love. no forwarding | 23:44 |
systemdlete | first question, when I bring up devuan graphical, there is a dark border all around the screen. and there does not seem to be a place to change the monitor settings | 23:45 |
systemdlete | when I go into the monitor settings dialog, I am already set for the largest size monitor | 23:46 |
systemdlete | missing driver? | 23:46 |
gnarface | maybe missing or just picked the wrong one by default. hard to say. i'd check the Xorg log first, to make sure the detected resolution and refresh settings match the display | 23:46 |
gnarface | sometimes it's just bad EDID data | 23:46 |
* systemdlete mounts the devuan partition to look at that. Good idea, gnarface | 23:46 | |
gnarface | "overscan" can be a graphics card setting too... it's usually not on by default but i vaguely recall some weird cases where it might be | 23:47 |
fsmithred | guest additions? | 23:48 |
systemdlete | hardware this time, fsmithred, hardware. :) | 23:48 |
systemdlete | (finally!) | 23:48 |
fsmithred | oh | 23:48 |
systemdlete | Yes, well, this is the result of having put up long enough with C6 as my host and needing to find a solution before 2020, when support for C6 totally runs out | 23:49 |
systemdlete | I'd like to have Devuan or something solid in place and soon | 23:50 |
systemdlete | oh, and this is Ascii, not Jessie or Beowulf or any other future release. | 23:50 |
systemdlete | It's a fresh install, from about 3 days ago. | 23:50 |
systemdlete | looks like ATI VESA... | 23:52 |
systemdlete | RS780 | 23:52 |
gnarface | Vega you mean? | 23:53 |
systemdlete | Xorg.0.log: VBESetVBEMode failed, mode set without customized refresh. | 23:53 |
systemdlete | no, VESA | 23:53 |
gnarface | definitely the wrong driver then | 23:53 |
gnarface | VESA is a generic driver | 23:54 |
gnarface | something it falls back on if it can't figure out what to use | 23:54 |
gnarface | at that point it's just trying to get any working display even if the feature support is severely limited | 23:55 |
systemdlete | this MB is from at least a generation ago. (AMD 3M) | 23:56 |
systemdlete | 3AM, sorry | 23:56 |
gnarface | VESA is a lot older than that | 23:56 |
systemdlete | AM3 rather | 23:56 |
gnarface | VESA isn't your best driver unless the video card is either completely unsupported, or... from the early 1990's | 23:57 |
systemdlete | It is loading a driver, a long list of ATI Radeon (and some others) | 23:57 |
gnarface | pastebin the xorg log? | 23:58 |
gnarface | by default if you haven't specified in the xorg.conf, it will actually try to load several drivers all at once to see what sticks | 23:59 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!