Re: [OpenWrt-Devel] flock clash with msmtpq-ng-mta
On 2019-01-07 4:57 p.m., Marcel Telka wrote: > On Sat, Jan 05, 2019 at 03:54:52AM -0500, Daniel F. Dickinson wrote: >> On 2019-01-04 2:14 a.m., Marcel Telka wrote: >>> Hi, >>> >>> After upgrade from LEDE 17.01.4 to OpenWrt 18.06.1 I noticed that >>> mailq from >>> the msmtpq-ng-mta package no longer works: >>> >> So I have bad news -- I'm upstream and I deprecated / abandoned the >> msmtpq-ng as a bad idea. I could probably be convinced to bring it back >> if there were use cases that actually made sense (what I realized is >> that the queuing was of limited use on flash system because a reboot >> loses all queued messages anyway in the default (RAM) config, and I >> wouldn't want to queue onto flash for limited writes concerns). If >> there was a good case I think I'd fixup the shell script only until I >> had replaced it with a decent C implementation of a similar concept >> (preferably using a reasonably small smtp library to do avoid >> reinventing the wheel). > > Okay, thanks for the info. > > My use case is simple: I have a site (small household) with only one device > running all the time (a cheap openwrt router). I would like to run some > non-critical cron jobs on the router and I'd like to get email notifications > from them once completed. I found that simple mail queue support as provided > by msmtpq-ng-mta is good enough to cover rare internet connection issues. I > do > not need to have a bullet proof system with zero lost mails, so in-RAM queue > is > good enough. When I did my research few years back to find the best solution > I > just found msmtpq-ng-mta and started to use it. It perfectly fits my needs. > A > possible solution with added some small additional device (like a Raspberry > Pi) > is just an overkill for this use case and cannot be reasonably justified. > > Is there any other simple solution that could be used for sending mails, > preferably with simple queuing support, and with ability to submit mails using > TLS and SMTP AUTH? > There isn't that I am aware of. I actually think I will pull the project out of mothball mode and do some updates. I'll try and look at the 18.06 branch and what can be done 'soon'. I may not make the merge window for the next batch of releases as I believe fork is on about the 12th. In the meantime have you tried installing 'full' flock and logger utilities? That may solve your issue for now. Regards, Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] mdadm: add new init features; documentation; bug fixes
This is a significant revision of /etc/init.d/mdadm. It adds new features, support for new configuration options, safer error handling, (configurable) verbose output, and contains multiple bug fixes. Most notably, mdadm was being started with the --config flag and that prevented it from using its built in Auto Assembly features. Users were required to put a correct uuid in /etc/config/mdadm. Configuring arrays is not for the feint of heart. The previous /etc/config/mdadm options left uncommented, that prevented mdadm from starting successfully, were corrected and the default startup mode is now to automatically assemble all RAID arrays attached to the machine using device scans rather than configuation options and a persistent state file. A new UCI section, config mdadm global, was added with new options that are supported by the accompanying /etc/init.d/mdadm. Documentation for all new (and previous) options was added as well. See the /etc/config/mdadmin or mdadm.init file itself for more details. Additionally, a new stateful 'auto' feature was added that functions similarly to the stateless Auto Assembly feature. The benefits of stateful auto assembly are to support features that mdadm 4.0 will only read from a configuration file, such as setting the MAILFROM value. The new mdadm_conf_auto() function will also greatly aid users in troubleshooting. When verbose is turned on it provides tips, better visibility for what's actually happening, and sets the stage for moderately advanced users to take more control over their RAIDs. Stateful UCI only configurations are still supported and will still work. All previously existing configurations will work in this mode. However, these users will now have to explicitly turn it on. Documentation is provided in the new mdadm.config file. I'd expect very few regressions. Anyone using the old init had to be an expert. The mdadm 4.0-5 package doesn't function out of the box. For more detail about these parts, see FS2043 here https://bugs.openwrt.org/ A new reload_service() function was added to prevent reloads from stopping mdadm. That caused issues when filesystems were mounted. Reloads will now be ignored, though the stage is set for reloads to trigger scans for new devices. Explicit restarts still work as expected. The start_service() function was enhanced to query new UCI mdadm.global options: alert_program, config, email, email_from, monitor_frequency, and verbose. Each is documented in /etc/mdadm/config (config.init) and some additional code comments were added. As well, error handling and verbose output was greatly enhanced. It's not going to do anything without users knowing what's going on (if verbose is turned on). Backward compatibility was retained. Strict reliance on a shell global ($CONF) was removed and replaced with a single global ($TMP_FILE) that's for development convenience. When/if a config file is not specified in the UCI config, it will fall back to using $TMP_FILE as the configuration file. Incremented PKG_RELEASE from 5 to 6 For more details, see: https://github.com/openwrt/openwrt/pull/1713/ Signed-off-by: Joseph Tingiris --- package/utils/mdadm/Makefile | 2 +- package/utils/mdadm/files/mdadm.config | 162 ++- package/utils/mdadm/files/mdadm.init | 491 +++-- 3 files changed, 615 insertions(+), 40 deletions(-) diff --git a/package/utils/mdadm/Makefile b/package/utils/mdadm/Makefile index ba74997..3fabc8a 100644 --- a/package/utils/mdadm/Makefile +++ b/package/utils/mdadm/Makefile @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk PKG_NAME:=mdadm PKG_VERSION:=4.0 -PKG_RELEASE:=5 +PKG_RELEASE:=6 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz PKG_SOURCE_URL:=@KERNEL/linux/utils/raid/mdadm diff --git a/package/utils/mdadm/files/mdadm.config b/package/utils/mdadm/files/mdadm.config index 50afbc2..88e0bb9 100644 --- a/package/utils/mdadm/files/mdadm.config +++ b/package/utils/mdadm/files/mdadm.config @@ -1,18 +1,154 @@ -config mdadm +# +# The mdadm 'global' section is for options that apply to all sections. +# + +config mdadm global + + # + # option 'alert_program' values may be a path to a valid, executable binary. + # + # The default 'alert_program' is not set. + # + # When mdadm detects an event it will execute this program with 3 arguments, see mdadm(8) + # $1 = will be the event + # $2 = will be the meta device + # $3 = may be a related component (if one exists) + # + # * alert_program runs independently from sendmail. + # * If both options alert_program and email are set, and both work, then an email and a + # custom alert will be generated. + # * no alert program is included in mdadm 4.0-4. + # + # Lots of possibilities exist, i.e. scripts for netdata, slack, etc. + # + #option alert_program /usr/sbin/mdadm_alerts + + + # + # option 'config'
Re: [OpenWrt-Devel] [PATCH experimental] quilt: Build a kernel git tree
On 2019-01-07 8:49 p.m., Daniel Santos wrote: > This is is mostly for those who've wanted something like this. It still > needs cleanup. > > This patch enables OpenWRT to re-construct a kernel git tree instead of > just extracting and patching the kernel sources to an essentially > temporary directory. It's VERY helpful when you're trying to backport, > git-blame, or just understand why a change was made. Details are in the > patch message and Kconfig documentation. > > If devs are interested in this patch for upstream I can clean it up. > As-is, it spits you to a shell if anything goes wrong, so only works > with -j1. Thanks for this -- I certainly like the concept and have made have-hearted attempts at it in my own copy of the the linux.git tree. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] config: kernel: Fix missing symbol on brcm2708 with CGROUPS
From: "Daniel F. Dickinson" When CGROUP block io is enabled a new symbol is exposed and needs to be set or unset else kernel oldconfig hangs waiting for input during normal OpenWrt builds. Therefore add sane defaults for this symbol in that case. Also, the defaults brcm2708 are different than generic defaults because the platform's defconfig enables BLK_DEV_THROTTLING by default (in defconfig config from the patches used to match upstream's kernel, not in OpenWrt config-4.xx). Signed-off-by: Daniel F. Dickinson --- config/Config-kernel.in | 17 + 1 file changed, 17 insertions(+) diff --git a/config/Config-kernel.in b/config/Config-kernel.in index f38cc792dd..6b571368f2 100644 --- a/config/Config-kernel.in +++ b/config/Config-kernel.in @@ -519,6 +519,23 @@ if KERNEL_CGROUPS CONFIG_CFQ_GROUP_IOSCHED=y; for enabling throttling policy, set CONFIG_BLK_DEV_THROTTLING=y. + if KERNEL_BLK_CGROUP + + config KERNEL_CFQ_GROUP_IOSCHED + bool "Proportional weight of disk bandwidth in CFQ" + default n if KERNEL_BLK_DEV_THROTTLING + default y + + config KERNEL_BLK_DEV_THROTTLING + bool "Enable throttling policy" + default y if TARGET_brcm2708 + default n + + config KERNEL_BLK_DEV_THROTTLING_LOW + bool "Block throttling .low limit interface support (EXPERIMENTAL)" + default n + endif + config KERNEL_DEBUG_BLK_CGROUP bool "Enable Block IO controller debugging" default n -- 2.11.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Do all devs follow GitHub or is list still the preferred discussion location?
On 2019-01-09 7:45 a.m., Jo-Philipp Wich wrote: > Hi, > > personally I rarely visit Github PRs these days, any discussions going > on there (in issues or PRs) will likely get overlooked by most devs. > > ~ Thanks. That's kind of what I thought. I don't suppose there is any chance of having a smaller, better maintained packages feed and luci feed with patch submissions by ML instead of GitHub? I find that PR's are too easy especially if I'm in an impatient mood and the rigour of ML submission helps keep that in check (at least now that I'm doing better than during the fork). I admit that's a kind of random wish but it seems to me it'd be beneficial. Regards, Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Do all devs follow GitHub or is list still the preferred discussion location?
Hi, personally I rarely visit Github PRs these days, any discussions going on there (in issues or PRs) will likely get overlooked by most devs. ~ Jo signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
