Joe
-
Posts
15 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by Joe
-
-
On 3/9/2018 at 8:13 AM, tkaiser said:
Grab 'iostat 5' and 'iotop -o -b -d5 -q -t -k | grep -v Total' and start to analyse what's happening at the block device and application layer forgetting about the filesystem layer in between!)
Simply open up two terminal windows, run both commands and let pi-hole/dnsmasq do their job. If you see real activity at the block device layer every few seconds you have to worry, if this happens only every few minutes you're fine.
Thanks I'd already followed these from your previous post and this is what led me to a what was probably a poor choice of words when I said "theory". It wasn't completely clear to me what I was looking at from iostat and iotop because the values are transient and not accumulative but I'm happy to say that dnsmasq looks fine, it's not circumventing / bypassing the commit=600 cache when writing to /var/log/pihole.log.
pihole has two persistence stores today, the /var/log/pihole.log file which is mandatory if you want any data logged for the web UI at all and also a sqlite db which is intended for longer term storage and this can be switched off completely.
-
10 hours ago, tkaiser said:
Check the PID of dnsmasq and let iotop report what's going on? You need to differentiate between 'total' and 'actual' writes as per iotop's manual page (one is filesystem activity and only the other is relevant since that's about writing to the layer below)
Thanks for the iotop tip. I ran some tests putting pihole / dnsmasq under load and from what I can see, "Actual DISK WRITE" intermittently shows activity whereas the dnsmasq process "DISK WRITE" shows much more activity. This gives weight to the theory that dnsmasq is not circumventing / bypassing the commit=600 cache flush write mechanism.
With this known, it's not as bad as I originally anticipated to switch off log2ram for pihole purposes.. but I still won't be doing here
There is a glimmer of hope for pihole users wanting to keep log2ram on although it's still some way off. I read that they've announced something called FTLDNS which is supposed to remove the need for a log file when it becomes active in pihole 4.0
-
pihole relies on dnsmasq to log to the /var/log/pihole.log. They extend dnsmasq configuration like this: https://github.com/pi-hole/pi-hole/blob/master/advanced/01-pihole.conf#L43. I completely understand if you don't want to go there and look at that btw, but they basically instruct dnsmasq to not use syslog and to write to the pihole.log file via the `log-facility` option (https://linux.die.net/man/8/dnsmasq)
It's really nice that armbian configures the commit=600 cache flush mechanism to the SD card but I'm afraid I don't know if dnsmasq will respect this
In terms of dealing with the problem in pihole / their default configuration, to me it seems altogether safer and more manageable to manually reconfigure dnsmasq in their 01-pihole.conf back to use syslog again, regain control of their firehose and offload all logging onto to some other device with HDD storage.
-
My take on this is that pihole today just doesn't play nicely with low volume mounts like a log2ram tmpfs. It can work but only at low scale. dnsmasq is an unrestricted firehose of data into the pihole.log file at the moment.
@tkaiser is correct that pihole guys do need to do something about this but my feeling is this is not a priority for them. I happened to pick up on one of the suggestions in their discourse forum that requested the ability to filter out unwanted log entries here: https://discourse.pi-hole.net/t/filter-out-sites-from-query-log/3843. If implemented that would go some way towards helping with this problem.
IMO what they need to do is make the logging system more flexible so it can log anywhere. I suppose with a manual tweak to /etc/dnsmasq.d/01-pihole.conf that could be done now to revert to syslog logging.
I think the options today are do the manual dnsmasq reconfiguration, point syslog to some other box with HDD storage and use some other UI to view what the pihole web admin gui provides (i.e. ELK stack), tread carefully with how you use pihole so it won't fill the file system or just switch off their log completely and live with no UI. I guess another option is to do what @lpuerto did, switch off log2ram and let it rip but that's not for me.
-
I thought it would sensible to get things to a more standard position so I formatted an sd card and flashed the latest armbian ubuntu mainline as-is. I'm now running: Armbian 5.34.171121 nightly Ubuntu 16.04.3 LTS 4.13.14-sunxi64 and most of the problems that I mentioned above have gone away. I apologize for wasting anyone's time, please ignore this.
-
On 12/16/2017 at 6:30 PM, Igor said:
You have been using a deprecated theme. Fixed.
magic, not a clue how that came about but thanks for whatever you did; it's now looking fine and is usable
-
is it css challenged at the moment or is it me? it looks like this here where the options to the right are overlapping making them difficult to use:
-
Hi all,
I'm currently running Armbian 5.36 Ubuntu 16.04.3 LTS 4.11.1-sun50iw2. This was / is a local armbian build that I performed a few months ago to resolve an issue that I saw at that time in the network stack that prevented ipsec working correctly. I've performed apt update / apt upgrade since however cat /proc/version still reports the version as that which I manually built back in June.
Fast forward to today and I'd like to try out some traffic shaping tc rules but I'm running into some difficulty, which is making me doubt if my kernel has the support needed for iproute2.
The following works without any issue to list existing rules on eth0:
root@nanopineo2:~# tc -s qdisc ls dev eth0 qdisc pfifo_fast 0: root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 Sent 1109245 bytes 4725 pkt (dropped 0, overlimits 0 requeues 26) backlog 0b 0p requeues 26
..where pfifo_fast is the default qdisc (queuing discipline) for eth0
If I attempt to remove this rule I see an RTNETLINK error:
root@nanopineo2:~# sudo tc qdisc del dev eth0 root RTNETLINK answers: No such file or directory
If I attempt to add a new rule I see the same RTNETLINK error:
root@nanopineo2:~# tc qdisc add dev eth0 root tbf rate 1000kbit latency 50ms burst 5000 RTNETLINK answers: No such file or directory
iproute2 is installed:
root@nanopineo2:~# apt list --installed | grep iproute2 WARNING: apt does not have a stable CLI interface. Use with caution in scripts. iproute2/xenial-updates,now 4.3.0-1ubuntu3.16.04.2 arm64 [installed]
..however I read here http://lartc.org/howto/lartc.iproute2.package.html that kernel netlink support is required for iproute2 to work properly and I'm not sure that I have it.
I'm almost sure that sch_netem should be present for it to work but this is not installed and as far as I can tell by looking at kernel source that I can find in github, this is not included as part of the sunxi kernel:
root@nanopineo2:~# modprobe sch_netem modprobe: FATAL: Module sch_netem not found in directory /lib/modules/4.11.1-sun50iw2
Does anyone have any idea what I need to do to get this working?
Thanks for any help
Joe
-
I totally winged it and won
I was unable to read the patch and translate what I was looking at into the change that needed to be made to /sources/linux-sun50i-dev/sunxi64-4.11.y/net/ipv4/esp4.c just by looking at the patch alone. So I cloned https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git and looked at Steffen Klassert's diff with SmartGit - this enabled me to see what change I "might" need to make.
Next I put the Armbian build system into CREATE_PATCHES mode, made the change and in an almost unbelievably way it seems that I've got this right first time. Armbian build created the attached kernel-sun50iw2-dev.patch file, applied it.
Now I've built strongswan on the neo2 and reconfigured my tunnel it finally seems to be working. It's early days but it's definitely a whole lot better than it was. Happy days.
-
I agree martinayotte it would be very nice to get this patch in early. I believe this is the progress of the patch at the moment:
Personally I'd like to get this patched into the experimental AllWinner H5 firmware build just to test if it fixes the problem but unfortunately I'm struggling to see how to graft this patch onto /sources/linux-sun50i-dev/sunxi64-4.11.y/net/ipv4/esp4.c. The sunxi64-4.11.y flavour of the esp4.c file is significantly different to the esp4.c file that this patch was created against / where this patch is at the moment. The patch certainly doesn't auto patch as-is via the Armbian build system, it just gets rejected.
I'd be very interested to hear all/any ideas about how to translate this patch to Armbian.
-
just a heads up:
I believe the H5 experimental is mainline based on the 4.11 kernel and there's probably not much anyone can do at the moment to get ipsec working on 4.11 until the https://patchwork.kernel.org/patch/9704017/ fix is more generally available. I'm certainly not up for patching and rebuilding the kernel myself anyway
-
The cause of this mystery is found by Noel Kuntze at StrongSwan: https://wiki.strongswan.org/issues/2351?issue_count=221&issue_position=3&next_issue_id=2349&prev_issue_id=2352#note-9
https://patchwork.kernel.org/patch/9704017/ : ipsec doesn't route TCP with 4.11 kernel
It looks like there's a fix but it's not found it's way into the Armbian Neo2 Experimental yet which I believe is based on 4.11. FriendlyArm Debian is also based on 4.11.
ipsec is basically broken everywhere right now
Perfect timing by me!
-
I've still not got this fully working but for me moment I have switched from armbian to the friendlyElec debian image and I'm seeing exactly the same behavior on that platform too.
I've raised an issue with strongswan and there's some more information and wireshark traffic captures over there: https://wiki.strongswan.org/issues/2351?issue_count=220&issue_position=2&next_issue_id=2349&prev_issue_id=2352
Very odd at this stage and I'm not convinced this actually is a strongswan issue at all..
-
I'm running what I believe is the latest experimental for the neo2 - 5.27.170601. This could well be a problem related to something that doesn't yet work in this build.
I've built strongswan on the neo and everything built fine and installed. ipsec starts and I'm able to bring a tunnel up to a remote vpn server that I know is fine and is verified working from some other box with identical connection and key configuration that I'm using on the neo2.
When the tunnel is brought up on the neo2 it seems I'm not able to get any traffic to flow i.e. curl api.ipify.org should return the public ip of the remote vpn server but it just hangs. When the tunnel is down the same curl command works fine.
This feels routing / firewall / NAT related but to be honest I don't know where to start digging now.
Does anyone have any suggestions? Anyone managed to get something similar working yet?
Cheers
Joe
/var/log file fills up to 100% using pihole
in Orange Pi Zero
Posted
I appreciate your thoughtful and detailed reply and agree this is a bit of a boring and complex area. I admit that I'm probably 80/20 here where I lean towards being cautious, do the right thing in terms of buying decent SD cards and test them for genuineness and performance, think about application risk areas e.g. pihole etc. In a way I'm probably over cautious where log2ram will remain enabled and I'll continue to look for ways where the goal is a readonly file system for the most part. At the same time I'd like for things to just reliably work but this is really an unrealistic dream and SD card applications do need careful consideration.
It might be boring and complex subject but you're doing a good job and staying interested. Please keep it up.