Menu
▾
▴
astlinux-devel — The AstLinux development environment, compilation, etc
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
(41) |
Apr
(35) |
May
(18) |
Jun
(5) |
Jul
(4) |
Aug
(37) |
Sep
(9) |
Oct
(20) |
Nov
(50) |
Dec
(217) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
(212) |
Feb
(76) |
Mar
(113) |
Apr
(88) |
May
(130) |
Jun
(54) |
Jul
(208) |
Aug
(223) |
Sep
(112) |
Oct
(63) |
Nov
(131) |
Dec
(103) |
| 2010 |
Jan
(247) |
Feb
(130) |
Mar
(43) |
Apr
(92) |
May
(40) |
Jun
(43) |
Jul
(43) |
Aug
(80) |
Sep
(44) |
Oct
(74) |
Nov
(21) |
Dec
(46) |
| 2011 |
Jan
(36) |
Feb
(11) |
Mar
(21) |
Apr
(33) |
May
(4) |
Jun
(12) |
Jul
(5) |
Aug
(20) |
Sep
|
Oct
(64) |
Nov
(26) |
Dec
(71) |
| 2012 |
Jan
(13) |
Feb
(24) |
Mar
(11) |
Apr
(2) |
May
(10) |
Jun
(5) |
Jul
(13) |
Aug
(7) |
Sep
(26) |
Oct
(22) |
Nov
(17) |
Dec
(16) |
| 2013 |
Jan
(6) |
Feb
(6) |
Mar
(6) |
Apr
(8) |
May
(20) |
Jun
|
Jul
(1) |
Aug
(4) |
Sep
(18) |
Oct
(3) |
Nov
(14) |
Dec
(33) |
| 2014 |
Jan
(26) |
Feb
(6) |
Mar
(69) |
Apr
(10) |
May
|
Jun
(8) |
Jul
(18) |
Aug
(22) |
Sep
(19) |
Oct
(17) |
Nov
|
Dec
(4) |
| 2015 |
Jan
(14) |
Feb
(18) |
Mar
|
Apr
|
May
(26) |
Jun
(8) |
Jul
(9) |
Aug
(10) |
Sep
(15) |
Oct
(2) |
Nov
(30) |
Dec
(33) |
| 2016 |
Jan
(1) |
Feb
(24) |
Mar
(19) |
Apr
(1) |
May
|
Jun
(3) |
Jul
(1) |
Aug
(1) |
Sep
(20) |
Oct
(5) |
Nov
(14) |
Dec
(4) |
| 2017 |
Jan
(15) |
Feb
(35) |
Mar
(10) |
Apr
(9) |
May
(14) |
Jun
(33) |
Jul
(1) |
Aug
(27) |
Sep
(7) |
Oct
|
Nov
(10) |
Dec
(15) |
| 2018 |
Jan
(29) |
Feb
|
Mar
(2) |
Apr
(1) |
May
(11) |
Jun
|
Jul
(1) |
Aug
(8) |
Sep
(11) |
Oct
(22) |
Nov
(9) |
Dec
(13) |
| 2019 |
Jan
(1) |
Feb
(7) |
Mar
(3) |
Apr
(21) |
May
(34) |
Jun
(36) |
Jul
(18) |
Aug
(17) |
Sep
(19) |
Oct
(8) |
Nov
(3) |
Dec
|
| 2020 |
Jan
|
Feb
(4) |
Mar
(8) |
Apr
(29) |
May
(50) |
Jun
(8) |
Jul
(2) |
Aug
(10) |
Sep
(1) |
Oct
(7) |
Nov
(9) |
Dec
(19) |
| 2021 |
Jan
(2) |
Feb
(9) |
Mar
(6) |
Apr
(21) |
May
(13) |
Jun
(11) |
Jul
(2) |
Aug
(1) |
Sep
(3) |
Oct
(26) |
Nov
(2) |
Dec
(16) |
| 2022 |
Jan
(8) |
Feb
(7) |
Mar
(1) |
Apr
(13) |
May
(1) |
Jun
(4) |
Jul
(4) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
| 2023 |
Jan
(2) |
Feb
(3) |
Mar
(16) |
Apr
|
May
(2) |
Jun
(1) |
Jul
(4) |
Aug
(13) |
Sep
(8) |
Oct
(6) |
Nov
(4) |
Dec
|
| 2024 |
Jan
(3) |
Feb
(3) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(5) |
Aug
|
Sep
(1) |
Oct
|
Nov
(5) |
Dec
|
| 2025 |
Jan
(4) |
Feb
(2) |
Mar
|
Apr
(11) |
May
(1) |
Jun
(9) |
Jul
(18) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Lonnie A. <li...@lo...> - 2024-09-28 18:02:18
|
Announcing AstLinux Release: 1.5.5 More Info: AstLinux Project https://www.astlinux-project.org/ AstLinux 1.5.5 Highlights: * Asterisk Versions: 16.30.0, 18.24.3, 20.9.3 * Linux Kernel 5.10.223, security and bug fixes * RUNNIX, version bump to runnix-0.6.19 * jitterentropy-rngd, new package, version 1.2.8, Random Number Generator (RNG) daemon. Previous rng-tools 'rngd' daemon is no longer used. * s3fs, new package, version 1.94, allows a user to mount an S3 bucket via FUSE filesystem * libcurl (curl) version bump to 8.9.1, security fix: CVE-2024-6874 * libxml2, version bump to 2.11.9, security fix: CVE-2024-40896 * iperf3, version bump to 3.17.1, security fix: CVE-2024-26306 * sngrep, version bump to 1.8.2, security fix * unbound, version bump to 1.21.0, security fix: CVE-2024-33655 * chrony, version bump to 4.6 * Monit, version bump to 5.34.0 * netcalc, version bump to 2.1.7 * sqlite, version bump to 3.46.1 * ca-certificates, update trusted root certificates 2024-07-02 * mac2vendor, oui.txt database snapshot 2024-09-14 * Asterisk '16se' (stable edition) version 16.30.0 is the last Asterisk 16.x "Legacy" version, built --without-pjproject and --without-dahdi * Package upgrades providing important security and bug fixes Full ChangeLog: https://raw.githubusercontent.com/astlinux-project/astlinux/1.5.5/docs/ChangeLog.txt All users are encouraged to upgrade, read the ChangeLog for the details. AstLinux Team _______________________________________________ Astlinux-users mailing list Ast...@li... https://lists.sourceforge.net/lists/listinfo/astlinux-users Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... |
|
From: Lonnie A. <li...@lo...> - 2024-07-10 11:44:31
|
Hi David, You are correct, I withdraw my "sym-link(s) on /mnt/kd/ to the S3 mount on /var/s3fs/mnt/" idea ... bad idea. Alternatively, the S3 mount could contain directories of config files, each with a "ver" file (or hash) that gets incremented (or re-hashed) when changes are made. A nightly cron script could compare local /mnt/kd/ config's "ver" file with the S3 mount config's "ver" file and rsync or cp the files, update the local "ver" file and restart the service. You might ask, how is the above better than a similar nightly cron script using scp to a tightly firewall'ed or VPN connected server? Some might say the S3 mount is simpler, many S3 providers support encryption at rest, some have redundancy by default. S3 access with Read/Only privileges is a good feature. Lonnie > On Jul 9, 2024, at 9:38 PM, David Kerr <Da...@Ke...> wrote: > > Is there any local caching of files and/or directory structure? And any offline support? I'm just wondering if someone uses this for file(s) that may be accessed during system boot... what happens if either the network link is down, or it takes a long time to establish an initial connection. Or is this just something that we shouldn't do? > > David. > > On Tue, Jul 9, 2024 at 8:09 PM Lonnie Abelbeck <li...@lo...> wrote: > > Awesome possibilities here. > > First thought is to store config files to be shared between systems. Do you think this would work? > > That should work, though it would probably require sym-link(s) on /mnt/kd/ to the S3 mount on /var/s3fs/mnt/ > > Easy to test with the Pre-Release VM > > Lonnie > > > > > On Jul 9, 2024, at 6:30 PM, Michael Knill <mic...@ip...> wrote: > > > > Awesome possibilities here. > > > > First thought is to store config files to be shared between systems. Do you think this would work? > > > > Regards > > Michael KnillFrom: Lonnie Abelbeck <li...@lo...> > > Sent: Saturday, 6 July 2024 11:43 PM > > To: AstLinux Users Mailing List <ast...@li...> > > Cc: AstLinux Developers Mailing List <ast...@li...> > > Subject: [Astlinux-devel] AstLinux Pre-Release with S3 object storage support (s3fs) > > Greetings, > > > > Pre-Release Version: astlinux-1.5-6098-6ab1c5 > > > > AstLinux Project -> Development > > https://www.astlinux-project.org/dev.html > > > > Of particular note is a new feature to mount S3 Object Storage. > > -- > > S3 Object Storage Client (s3fs) > > https://doc.astlinux-project.org/userdoc:tt_s3_object_storage_client > > -- > > > > One interesting use case for s3fs is to provide a Read/Only mount to an S3 bucket containing a custom AstLinux firmware repository. > > -- > > https://doc.astlinux-project.org/userdoc:tt_s3_object_storage_client#custom_firmware_repository > > -- > > > > I'm sure there are many other interesting use cases. If you are so inclined, spin-up the beta Install ISO and give it a test. > > > > I personally tested it with: Linode (Akamai), Vultr, Backblaze B2, Cloudflare R2 (all but Vultr supports limited access keys) > > > > > > Complete Pre-Release ChangeLog: > > https://astlinux-project.org/beta/astlinux-changelog/ChangeLog.txt > > > > The "AstLinux Pre-Release ChangeLog" and "Pre-Release Repository URL" entries can be found under the "Development" tab of the AstLinux Project web site ... > > > > AstLinux Project -> Development > > https://www.astlinux-project.org/dev.html > > > > > > AstLinux Team > > > > > > > > _______________________________________________ > > Astlinux-devel mailing list > > Ast...@li... > > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > _______________________________________________ > > Astlinux-devel mailing list > > Ast...@li... > > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: David K. <da...@ke...> - 2024-07-10 02:39:10
|
Is there any local caching of files and/or directory structure? And any offline support? I'm just wondering if someone uses this for file(s) that may be accessed during system boot... what happens if either the network link is down, or it takes a long time to establish an initial connection. Or is this just something that we shouldn't do? David. On Tue, Jul 9, 2024 at 8:09 PM Lonnie Abelbeck <li...@lo...> wrote: > > Awesome possibilities here. > > First thought is to store config files to be shared between systems. Do > you think this would work? > > That should work, though it would probably require sym-link(s) on /mnt/kd/ > to the S3 mount on /var/s3fs/mnt/ > > Easy to test with the Pre-Release VM > > Lonnie > > > > > On Jul 9, 2024, at 6:30 PM, Michael Knill < > mic...@ip...> wrote: > > > > Awesome possibilities here. > > > > First thought is to store config files to be shared between systems. Do > you think this would work? > > > > Regards > > Michael KnillFrom: Lonnie Abelbeck <li...@lo...> > > Sent: Saturday, 6 July 2024 11:43 PM > > To: AstLinux Users Mailing List <ast...@li...> > > Cc: AstLinux Developers Mailing List < > ast...@li...> > > Subject: [Astlinux-devel] AstLinux Pre-Release with S3 object storage > support (s3fs) > > Greetings, > > > > Pre-Release Version: astlinux-1.5-6098-6ab1c5 > > > > AstLinux Project -> Development > > https://www.astlinux-project.org/dev.html > > > > Of particular note is a new feature to mount S3 Object Storage. > > -- > > S3 Object Storage Client (s3fs) > > https://doc.astlinux-project.org/userdoc:tt_s3_object_storage_client > > -- > > > > One interesting use case for s3fs is to provide a Read/Only mount to an > S3 bucket containing a custom AstLinux firmware repository. > > -- > > > https://doc.astlinux-project.org/userdoc:tt_s3_object_storage_client#custom_firmware_repository > > -- > > > > I'm sure there are many other interesting use cases. If you are so > inclined, spin-up the beta Install ISO and give it a test. > > > > I personally tested it with: Linode (Akamai), Vultr, Backblaze B2, > Cloudflare R2 (all but Vultr supports limited access keys) > > > > > > Complete Pre-Release ChangeLog: > > https://astlinux-project.org/beta/astlinux-changelog/ChangeLog.txt > > > > The "AstLinux Pre-Release ChangeLog" and "Pre-Release Repository URL" > entries can be found under the "Development" tab of the AstLinux Project > web site ... > > > > AstLinux Project -> Development > > https://www.astlinux-project.org/dev.html > > > > > > AstLinux Team > > > > > > > > _______________________________________________ > > Astlinux-devel mailing list > > Ast...@li... > > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > _______________________________________________ > > Astlinux-devel mailing list > > Ast...@li... > > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > |
|
From: Lonnie A. <li...@lo...> - 2024-07-10 00:09:40
|
> Awesome possibilities here. > First thought is to store config files to be shared between systems. Do you think this would work? That should work, though it would probably require sym-link(s) on /mnt/kd/ to the S3 mount on /var/s3fs/mnt/ Easy to test with the Pre-Release VM Lonnie > On Jul 9, 2024, at 6:30 PM, Michael Knill <mic...@ip...> wrote: > > Awesome possibilities here. > > First thought is to store config files to be shared between systems. Do you think this would work? > > Regards > Michael KnillFrom: Lonnie Abelbeck <li...@lo...> > Sent: Saturday, 6 July 2024 11:43 PM > To: AstLinux Users Mailing List <ast...@li...> > Cc: AstLinux Developers Mailing List <ast...@li...> > Subject: [Astlinux-devel] AstLinux Pre-Release with S3 object storage support (s3fs) > Greetings, > > Pre-Release Version: astlinux-1.5-6098-6ab1c5 > > AstLinux Project -> Development > https://www.astlinux-project.org/dev.html > > Of particular note is a new feature to mount S3 Object Storage. > -- > S3 Object Storage Client (s3fs) > https://doc.astlinux-project.org/userdoc:tt_s3_object_storage_client > -- > > One interesting use case for s3fs is to provide a Read/Only mount to an S3 bucket containing a custom AstLinux firmware repository. > -- > https://doc.astlinux-project.org/userdoc:tt_s3_object_storage_client#custom_firmware_repository > -- > > I'm sure there are many other interesting use cases. If you are so inclined, spin-up the beta Install ISO and give it a test. > > I personally tested it with: Linode (Akamai), Vultr, Backblaze B2, Cloudflare R2 (all but Vultr supports limited access keys) > > > Complete Pre-Release ChangeLog: > https://astlinux-project.org/beta/astlinux-changelog/ChangeLog.txt > > The "AstLinux Pre-Release ChangeLog" and "Pre-Release Repository URL" entries can be found under the "Development" tab of the AstLinux Project web site ... > > AstLinux Project -> Development > https://www.astlinux-project.org/dev.html > > > AstLinux Team > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: Michael K. <mic...@ip...> - 2024-07-10 00:03:30
|
Awesome possibilities here. First thought is to store config files to be shared between systems. Do you think this would work? Regards Michael Knill ________________________________ From: Lonnie Abelbeck <li...@lo...> Sent: Saturday, 6 July 2024 11:43 PM To: AstLinux Users Mailing List <ast...@li...> Cc: AstLinux Developers Mailing List <ast...@li...> Subject: [Astlinux-devel] AstLinux Pre-Release with S3 object storage support (s3fs) Greetings, Pre-Release Version: astlinux-1.5-6098-6ab1c5 AstLinux Project -> Development https://www.astlinux-project.org/dev.html Of particular note is a new feature to mount S3 Object Storage. -- S3 Object Storage Client (s3fs) https://doc.astlinux-project.org/userdoc:tt_s3_object_storage_client -- One interesting use case for s3fs is to provide a Read/Only mount to an S3 bucket containing a custom AstLinux firmware repository. -- https://doc.astlinux-project.org/userdoc:tt_s3_object_storage_client#custom_firmware_repository -- I'm sure there are many other interesting use cases. If you are so inclined, spin-up the beta Install ISO and give it a test. I personally tested it with: Linode (Akamai), Vultr, Backblaze B2, Cloudflare R2 (all but Vultr supports limited access keys) Complete Pre-Release ChangeLog: https://astlinux-project.org/beta/astlinux-changelog/ChangeLog.txt The "AstLinux Pre-Release ChangeLog" and "Pre-Release Repository URL" entries can be found under the "Development" tab of the AstLinux Project web site ... AstLinux Project -> Development https://www.astlinux-project.org/dev.html AstLinux Team _______________________________________________ Astlinux-devel mailing list Ast...@li... https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: Lonnie A. <li...@lo...> - 2024-07-06 13:44:11
|
Greetings, Pre-Release Version: astlinux-1.5-6098-6ab1c5 AstLinux Project -> Development https://www.astlinux-project.org/dev.html Of particular note is a new feature to mount S3 Object Storage. -- S3 Object Storage Client (s3fs) https://doc.astlinux-project.org/userdoc:tt_s3_object_storage_client -- One interesting use case for s3fs is to provide a Read/Only mount to an S3 bucket containing a custom AstLinux firmware repository. -- https://doc.astlinux-project.org/userdoc:tt_s3_object_storage_client#custom_firmware_repository -- I'm sure there are many other interesting use cases. If you are so inclined, spin-up the beta Install ISO and give it a test. I personally tested it with: Linode (Akamai), Vultr, Backblaze B2, Cloudflare R2 (all but Vultr supports limited access keys) Complete Pre-Release ChangeLog: https://astlinux-project.org/beta/astlinux-changelog/ChangeLog.txt The "AstLinux Pre-Release ChangeLog" and "Pre-Release Repository URL" entries can be found under the "Development" tab of the AstLinux Project web site ... AstLinux Project -> Development https://www.astlinux-project.org/dev.html AstLinux Team |
|
From: Lonnie A. <li...@lo...> - 2024-05-30 19:10:57
|
Announcing AstLinux Release: 1.5.4 More Info: AstLinux Project https://www.astlinux-project.org/ AstLinux 1.5.4 Highlights: * Asterisk Versions: 16.30.0, 18.22.0, 20.7.0 * Linux Kernel 5.10.216, security and bug fixes * RUNNIX, version bump to runnix-0.6.18 * atlantic, enable the Marvell (Aquantia) 10-Gigabit Ethernet Network Driver (Aquantia AQC107/AQC113/etc. support) * r8125, version 9.013.02, Realtek RTL8125 2.5-Gigabit Ethernet Network Driver * libcurl (curl) version bump to 8.7.1, security fixes: CVE-2024-0853, CVE-2024-2004, CVE-2024-2379, CVE-2024-2398, CVE-2024-2466 * expat, version bump to 2.6.2, security fixes: CVE-2023-52425, CVE-2023-52426, CVE-2024-28757 * libxml2, version bump to 2.11.8, security fixes: CVE-2024-25062, CVE-2024-34459 * php, version 7.2.34, add security fixes: CVE-2024-2756, CVE-2024-3096 * sngrep, version bump to 1.8.1, security fix: CVE-2024-3120 * tinyproxy, version bump to 1.11.2, security fix: CVE-2023-49606 * unbound, version bump to 1.19.3, security fixes: CVE-2023-50387, CVE-2023-50868, CVE-2024-1931 * fping, version bump to 5.2 * htop, version bump to 3.3.0 * msmtp, version bump to 1.8.26 * sqlite, version bump to 3.45.3 * stunnel, version bump to 5.72 * vnStat, version bump to 2.12 * ca-certificates, update trusted root certificates 2024-03-11 * mac2vendor, oui.txt database snapshot 2024-05-22 * Asterisk '16se' (stable edition) version 16.30.0 is the last Asterisk 16.x "Legacy" version, built --without-pjproject and --without-dahdi * Package upgrades providing important security and bug fixes Full ChangeLog: https://raw.githubusercontent.com/astlinux-project/astlinux/1.5.4/docs/ChangeLog.txt All users are encouraged to upgrade, read the ChangeLog for the details. AstLinux Team |
|
From: Michael K. <mic...@ip...> - 2024-02-18 20:01:20
|
Hi Lonnie Great news. Thanks for that. I did ask my provider account manager whether these changes would impact pricing and he said that they would be cost neutral for them so that’s good to hear. Regards Michael Knill From: Lonnie Abelbeck <li...@lo...> Date: Friday, 16 February 2024 at 11:13 am To: AstLinux Developers Mailing List <ast...@li...> Subject: Re: [Astlinux-devel] [Astlinux-users] VMware by Broadcom Hi Michael, Thanks for the feedback. Great to hear how things are used in the real world. Hope your VMware vCloud environment costs don't go up too much in the future. No worries, we will keep VMware kernel support and hopefully open-vm-tools stays relevant. We may want to tweak the documentation related to ESXi and such. Lonnie > On Feb 15, 2024, at 4:47 PM, Michael Knill <mic...@ip...> wrote: > > Hi Lonnie > > Responded on the Developer mailing list. > > Please please don’t remove VMware support ☹ > Our new architecture is installing Astlinux in our VMware vCloud environment of which we have around 50 systems with many more to come. We no longer install hardware based Astlinux except the occasional VPN gateway on a spare APU and install ALL our systems in vCloud with connectivity from VPN devices such as Netgate (pfSense) and GL.iNet (OpenWRT). > > Its an excellent architecture as we can oversubscribe CPU and with the low Astlinux memory footprint (now 300M), cloud servers are very cost effective. As this is provided as a service there is no impact to me unless it affects my provider which I suspect it wont but if so it would only be pricing. > > Regards > Michael Knill > > > From: Lonnie Abelbeck <li...@lo...> > Date: Friday, 16 February 2024 at 1:24 am > To: AstLinux Users Mailing List <ast...@li...> > Subject: [Astlinux-users] VMware by Broadcom > > Hi Group, > > With the VMware transition from perpetual licensing to new subscription offerings, and the end of free ESXi [1], > > should the VMware support in AstLinux change in any way? > > If you are currently using AstLinux in a VMware instance, will you continue to do so for the future or switch to some other hypervisor? > > There is some extra bloat added to the AstLinux VM ISO to support VMware (ex. open-vm-tools) > > I'm curious how AstLinux VM users are reacting to the VMware transition. > > Lonnie > > [1] https://kb.vmware.com/s/article/2107518 > > > > > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel _______________________________________________ Astlinux-devel mailing list Ast...@li... https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: Lonnie A. <li...@lo...> - 2024-02-16 00:13:05
|
Hi Michael, Thanks for the feedback. Great to hear how things are used in the real world. Hope your VMware vCloud environment costs don't go up too much in the future. No worries, we will keep VMware kernel support and hopefully open-vm-tools stays relevant. We may want to tweak the documentation related to ESXi and such. Lonnie > On Feb 15, 2024, at 4:47 PM, Michael Knill <mic...@ip...> wrote: > > Hi Lonnie > > Responded on the Developer mailing list. > > Please please don’t remove VMware support ☹ > Our new architecture is installing Astlinux in our VMware vCloud environment of which we have around 50 systems with many more to come. We no longer install hardware based Astlinux except the occasional VPN gateway on a spare APU and install ALL our systems in vCloud with connectivity from VPN devices such as Netgate (pfSense) and GL.iNet (OpenWRT). > > Its an excellent architecture as we can oversubscribe CPU and with the low Astlinux memory footprint (now 300M), cloud servers are very cost effective. As this is provided as a service there is no impact to me unless it affects my provider which I suspect it wont but if so it would only be pricing. > > Regards > Michael Knill > > > From: Lonnie Abelbeck <li...@lo...> > Date: Friday, 16 February 2024 at 1:24 am > To: AstLinux Users Mailing List <ast...@li...> > Subject: [Astlinux-users] VMware by Broadcom > > Hi Group, > > With the VMware transition from perpetual licensing to new subscription offerings, and the end of free ESXi [1], > > should the VMware support in AstLinux change in any way? > > If you are currently using AstLinux in a VMware instance, will you continue to do so for the future or switch to some other hypervisor? > > There is some extra bloat added to the AstLinux VM ISO to support VMware (ex. open-vm-tools) > > I'm curious how AstLinux VM users are reacting to the VMware transition. > > Lonnie > > [1] https://kb.vmware.com/s/article/2107518 > > > > > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: Michael K. <mic...@ip...> - 2024-02-15 23:21:49
|
Hi Lonnie Responded on the Developer mailing list. Please please don’t remove VMware support ☹ Our new architecture is installing Astlinux in our VMware vCloud environment of which we have around 50 systems with many more to come. We no longer install hardware based Astlinux except the occasional VPN gateway on a spare APU and install ALL our systems in vCloud with connectivity from VPN devices such as Netgate (pfSense) and GL.iNet (OpenWRT). Its an excellent architecture as we can oversubscribe CPU and with the low Astlinux memory footprint (now 300M), cloud servers are very cost effective. As this is provided as a service there is no impact to me unless it affects my provider which I suspect it wont but if so it would only be pricing. Regards Michael Knill From: Lonnie Abelbeck <li...@lo...> Date: Friday, 16 February 2024 at 1:24 am To: AstLinux Users Mailing List <ast...@li...> Subject: [Astlinux-users] VMware by Broadcom Hi Group, With the VMware transition from perpetual licensing to new subscription offerings, and the end of free ESXi [1], should the VMware support in AstLinux change in any way? If you are currently using AstLinux in a VMware instance, will you continue to do so for the future or switch to some other hypervisor? There is some extra bloat added to the AstLinux VM ISO to support VMware (ex. open-vm-tools) I'm curious how AstLinux VM users are reacting to the VMware transition. Lonnie [1] https://kb.vmware.com/s/article/2107518 _______________________________________________ Astlinux-users mailing list Ast...@li... https://lists.sourceforge.net/lists/listinfo/astlinux-users Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... |
|
From: Lonnie A. <li...@lo...> - 2024-01-31 15:56:42
|
Announcing AstLinux Release: 1.5.3 More Info: AstLinux Project https://www.astlinux-project.org/ AstLinux 1.5.3 Highlights: * Asterisk Versions: 16.30.0, 18.20.2, 20.5.2 * Linux Kernel 5.10.205, security and bug fixes * RUNNIX, version bump to runnix-0.6.17 * i40e, enable the Intel 10-Gigabit Ethernet Network Driver (Intel X710/XL710/XXV710/X722 support) * r8125, version 9.012.04, Realtek RTL8125 2.5-Gigabit Ethernet Network Driver * OpenSSH, version bump to 8.4p1, security fixes: CVE-2021-28041, CVE-2021-41617, CVE-2023-48795, CVE-2023-51385 * libcurl (curl) version bump to 8.5.0, security fixes: CVE-2023-46218, CVE-2023-46219 * libxml2, version bump to 2.11.6 * chrony, version bump to 4.5 * php, version 7.2.34, add security fix: CVE-2023-3823 * sngrep, version bump to 1.8.0 * sqlite, version bump to 3.44.2 * udev (eudev), version bump to 3.2.14 * unbound, version bump to 1.19.0 * ca-certificates, update trusted root certificates 2023-12-12 * Asterisk '16se' (stable edition) version 16.30.0 is the last Asterisk 16.x "Legacy" version, built --without-pjproject and --without-dahdi * Package upgrades providing important security and bug fixes Full ChangeLog: https://raw.githubusercontent.com/astlinux-project/astlinux/1.5.3/docs/ChangeLog.txt All users are encouraged to upgrade, read the ChangeLog for the details. AstLinux Team |
|
From: Michael K. <li...@mk...> - 2024-01-07 17:52:02
|
Hi group, has someone successfully got Docker running in an AstLinux LXC container? I know in Proxmox in the options for a container "keyctl=1,nesting=1" has to be set, to get Docker to run in a container. But I can't get this working in AstLinux. I tried Debian 11 and Ubuntu 22.04, on both Docker installed, but failed to start. Michael http://www.mksolutions.info |
|
From: Lonnie A. <li...@lo...> - 2024-01-06 18:41:12
|
Announcing AstLinux Pre-Release: astlinux-1.5-5979-ce0ecf AstLinux Project -> Development https://www.astlinux-project.org/dev.html ** The AstLinux Team is regularly upgrading packages containing security and bug fixes as well as adding new features of our own. -- Linux Kernel 5.10.205 (version bump), security and bug fixes -- i40e, enable the Intel 10-Gigabit Ethernet Network Driver (Intel X710/XL710/XXV710/X722 support) -- r8125, version 9.012.04, Realtek RTL8125 2.5-Gigabit Ethernet Network Driver -- OpenSSH, version bump to 8.4p1, security fixes: CVE-2021-28041, CVE-2021-41617, CVE-2023-48795, CVE-2023-51385 -- libcurl (curl) version bump to 8.5.0, security fixes: CVE-2023-46218, CVE-2023-46219 -- php, version 7.2.34, add security fix: CVE-2023-3823 -- chrony, version bump to 4.5 -- empty, version bump to 0.6.23c Note: Minor tweaks to any scripts using 'empty' may be needed. Example: empty -w "$expect" -> empty -w "$expect" '' -- sngrep, version bump to 1.8.0 -- sqlite, version bump to 3.44.2 -- unbound, version bump to 1.19.0 -- ca-certificates, update trusted root certificates 2023-12-12 -- Asterisk 16.30.0 ('16se' no change) Last Asterisk 16.x "Legacy" version, built --without-pjproject and --without-dahdi -- Asterisk 18.20.2 (version bump) and 20.5.2 (version bump) Built --with-pjproject and --with-dahdi -- DAHDI, dahdi-linux 3.2.0 (no change) and dahdi-tools 3.2.0 (no change) Add build fix to include "astribank" utilities -- Added rc.conf variable DAHDI_DISABLE, disable DAHDI when set to "yes", defaults to "no". -- Complete Pre-Release ChangeLog: https://astlinux-project.org/beta/astlinux-changelog/ChangeLog.txt The "AstLinux Pre-Release ChangeLog" and "Pre-Release Repository URL" entries can be found under the "Development" tab of the AstLinux Project web site ... AstLinux Project -> Development https://www.astlinux-project.org/dev.html AstLinux Team |
|
From: Michael K. <mic...@ip...> - 2023-11-21 22:47:26
|
Thanks Lonnie Regards Michael Knill From: Lonnie Abelbeck <li...@lo...> Date: Wednesday, 22 November 2023 at 7:14 am To: AstLinux Developers Mailing List <ast...@li...> Subject: Re: [Astlinux-devel] OpenSSL 1.1.1 EoL Hi Michael, The team has discussed what it would take switching to OpenSSL 3.0.x . Sadly it is never simple. AstLinux has about 32 packages that use OpenSSL. For the OpenSSL 1.0.2 -> 1.1.1 transition (2018-2019) every package required code changes to use OpenSSL 1.1.1. As such it took almost a year after the 1.0.2 EOL date before 1.1.1 was a practical replacement. For the OpenSSL 1.1.1 -> 3.0.x transition (2023-2024) things are not as dire, in theory many/most packages should compile without changes but generates deprecation warnings at compile time. Very few packages natively support OpenSSL 3.0.x. We will know more when we dig into the issue. The good news is Debian supports OpenSSL 1.1.1 in both buster (security) and bullseye (security) [1]. If there are any major CVEs discovered in 1.1.1, fixes should appear as patches until we can switch to 3.0.x. Keep in mind that newer does not imply better. For example OpenVPN CVE-2023-46850 [2] does not effect OpenVPN 2.4.x or 2.5.x. Lonnie [1] https://security-tracker.debian.org/tracker/source-package/openssl [2] https://security-tracker.debian.org/tracker/CVE-2023-46850 > On Nov 21, 2023, at 1:36 AM, Michael Knill <mic...@ip...> wrote: > > Just wondering how this is going to affect Astlinux and specifically OpenVPN which I use quite a bit. > I know pfSense has moved to OpenSSL 3.0 for this reason and it was not an easy update? > > Regards > > Michael Knill > Managing Director > > D: +61 2 6189 1360 > P: +61 2 6140 4656 > E: mic...@ip... > W: ipcsolutions.com.au > > <image001.png> > Smarter Business Communications > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel _______________________________________________ Astlinux-devel mailing list Ast...@li... https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: Lonnie A. <li...@lo...> - 2023-11-21 20:14:32
|
Hi Michael, The team has discussed what it would take switching to OpenSSL 3.0.x . Sadly it is never simple. AstLinux has about 32 packages that use OpenSSL. For the OpenSSL 1.0.2 -> 1.1.1 transition (2018-2019) every package required code changes to use OpenSSL 1.1.1. As such it took almost a year after the 1.0.2 EOL date before 1.1.1 was a practical replacement. For the OpenSSL 1.1.1 -> 3.0.x transition (2023-2024) things are not as dire, in theory many/most packages should compile without changes but generates deprecation warnings at compile time. Very few packages natively support OpenSSL 3.0.x. We will know more when we dig into the issue. The good news is Debian supports OpenSSL 1.1.1 in both buster (security) and bullseye (security) [1]. If there are any major CVEs discovered in 1.1.1, fixes should appear as patches until we can switch to 3.0.x. Keep in mind that newer does not imply better. For example OpenVPN CVE-2023-46850 [2] does not effect OpenVPN 2.4.x or 2.5.x. Lonnie [1] https://security-tracker.debian.org/tracker/source-package/openssl [2] https://security-tracker.debian.org/tracker/CVE-2023-46850 > On Nov 21, 2023, at 1:36 AM, Michael Knill <mic...@ip...> wrote: > > Just wondering how this is going to affect Astlinux and specifically OpenVPN which I use quite a bit. > I know pfSense has moved to OpenSSL 3.0 for this reason and it was not an easy update? > > Regards > > Michael Knill > Managing Director > > D: +61 2 6189 1360 > P: +61 2 6140 4656 > E: mic...@ip... > W: ipcsolutions.com.au > > <image001.png> > Smarter Business Communications > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: Michael K. <mic...@ip...> - 2023-11-21 07:36:52
|
Just wondering how this is going to affect Astlinux and specifically OpenVPN which I use quite a bit. I know pfSense has moved to OpenSSL 3.0 for this reason and it was not an easy update? Regards Michael Knill Managing Director D: +61 2 6189 1360<tel:+61261891360> P: +61 2 6140 4656<tel:+61261404656> E: mic...@ip...<mailto:mic...@ip...> W: ipcsolutions.com.au<https://ipcsolutions.com.au/> [Icon Description automatically generated] Smarter Business Communications |
|
From: Lonnie A. <li...@lo...> - 2023-11-16 13:33:35
|
Announcing AstLinux Release: 1.5.2 More Info: AstLinux Project https://www.astlinux-project.org/ Changes to supported firmware builds: * Previous 'ast13se' and 'ast16' firmware branches are no longer updated. * New 'ast16se' firmware branch, Asterisk 16.x built --without-pjproject and --without-dahdi * Previous 'ast18' firmware branch, Asterisk 18.x built --with-pjproject and --with-dahdi * New 'ast20' firmware branch, Asterisk 20.x built --with-pjproject and --with-dahdi AstLinux 1.5.2 Highlights: * Asterisk Versions: 16.30.0, 18.20.0, 20.5.0 * Linux Kernel 5.10.197, security and bug fixes * RUNNIX, version bump to runnix-0.6.16 * OpenSSL, version bump to 1.1.1w, security fixes: CVE-2023-3446, CVE-2023-3817 * libcurl (curl) version bump to 8.4.0, security fixes: CVE-2023-38039, CVE-2023-38545, CVE-2023-38546 * LibreTLS, version bump to 3.8.1 * libpng, version bump to 1.6.40 * libsodium, version bump to 1.0.19 * libxml2, version bump to 2.11.5 * chrony, version bump to 4.4 * ne, version bump to 3.3.3 * msmtp, version bump to 1.8.25 * netsnmp, version bump to 5.9.4 * pjsip version bump to 2.13.1 * screen, version 4.9.1, security fix: CVE-2023-24626 * sqlite, version bump to 3.43.2 * sqliteodbc, version bump to 0.99991 * tiff, version bump to 4.6.0 * unbound, version bump to 1.18.0 * unixodbc, version bump to 2.3.12 * vnStat, version bump to 2.11 * zabbix, version bump to 4.0.50 * Asterisk '16se' (stable edition) version 16.30.0 is the last Asterisk 16.x "Legacy" version, built --without-pjproject and --without-dahdi * Package upgrades providing important security and bug fixes Full ChangeLog: https://raw.githubusercontent.com/astlinux-project/astlinux/1.5.2/docs/ChangeLog.txt All users are encouraged to upgrade, read the ChangeLog for the details. AstLinux Team |
|
From: Lonnie A. <li...@lo...> - 2023-10-08 17:52:59
|
Announcing AstLinux Pre-Release: astlinux-1.5-5906-4212c3 AstLinux Project -> Development https://www.astlinux-project.org/dev.html ** IMPORTANT NOTICE -- Changes to supported firmware builds: == Previous 'ast13se' and 'ast16' firmware branches are no longer updated. == New 'ast16se' firmware branch, Asterisk 16.x built --without-pjproject and --without-dahdi == Previous 'ast18' firmware branch, Asterisk 18.x built --with-pjproject and --with-dahdi == New 'ast20' firmware branch, Asterisk 20.x built --with-pjproject and --with-dahdi ** The AstLinux Team is regularly upgrading packages containing security and bug fixes as well as adding new features of our own. -- Linux Kernel 5.10.197 (version bump), security and bug fixes -- OpenSSL, version bump to 1.1.1w, security fixes: CVE-2023-3446, CVE-2023-3817 -- chrony, version bump to 4.4 -- cron (busybox), add logging methods and levels. The defaults remain the same as previous. New rc.conf variables: CRON_LOG_METHOD and CRON_LOG_LEVEL -- libcurl (curl) version bump to 8.3.0, security fix: CVE-2023-38039 -- libxml2, version bump to 2.11.5 -- msmtp, version bump to 1.8.24 -- netsnmp, version bump to 5.9.4 -- screen, version 4.9.1, security fix: CVE-2023-24626 -- smartctl (smartmontools), version bump to 7.4, drivedb.h snapshot 2023-08-19 -- sqlite, version bump to 3.43.1 -- tinyproxy, version 1.11.1, now included in the standard builds, but disabled by default -- unixodbc, version bump to 2.3.12 -- upgrade-run-image, limit "noram" loop mount from being removed during upgrade. -- unbound, version bump to 1.18.0 -- vnStat, version bump to 2.11 -- zlib, version bump to 1.3 -- ca-certificates, update trusted root certificates 2023-08-22 -- Asterisk 16.30.0 ('16se' version bump) Last Asterisk 16.x "Legacy" version, built --without-pjproject and --without-dahdi -- Asterisk 18.19.0 (version bump) and 20.4.0 (new version) Built --with-pjproject and --with-dahdi Disable: STIR/SHAKEN support -- DAHDI, dahdi-linux 3.2.0 (no change) and dahdi-tools 3.2.0 (no change) Add build fix to include "astribank" utilities -- Added rc.conf variable DAHDI_DISABLE, disable DAHDI when set to "yes", defaults to "no". -- pjsip 2.13.1 (version bump) -- libpri, version bump to 1.6.1 -- Complete Pre-Release ChangeLog: https://astlinux-project.org/beta/astlinux-changelog/ChangeLog.txt The "AstLinux Pre-Release ChangeLog" and "Pre-Release Repository URL" entries can be found under the "Development" tab of the AstLinux Project web site ... AstLinux Project -> Development https://www.astlinux-project.org/dev.html AstLinux Team |
|
From: Michael K. <mic...@ip...> - 2023-10-03 23:24:37
|
A cool thanks Lonnie. We will change this in the interim. Regards Michael Knill From: Lonnie Abelbeck <li...@lo...> Date: Wednesday, 4 October 2023 at 7:14 am To: AstLinux Developers Mailing List <ast...@li...> Subject: Re: [Astlinux-devel] [Astlinux-users] Stopping logging of Crontab Update. It seems Michael (DE) was correct to whether a crond log-level existed for "error" logging and not "info" logging. Commit here [1] While the busybox crond only talks about a least verbose (default) level of "8", looking at the code a level of "9" can be used to ignore the "info" logs and only log "error" logs. Quite a few github projects use "crond -l 9" to get "error" only logs for syslog. More info here [2] Michael (AU), while using "crond -L /dev/null" is a valid way to ignore all logs, "crond -l 9" may be better in general to show crontab syntax errors. -- ## Cron Daemon #CRON_LOG_METHOD="file" # Log Methods: "syslog", "file" (/var/log/cron.log), or "none". Default is "syslog" #CRON_LOG_LEVEL="error" # Log Levels: "info" or "error". Default is "info" -- Lonnie [1] https://github.com/astlinux-project/astlinux/commit/3aaf769d50bc656ecfe3375ec7e93b3ba0c77375 [2] https://unix.stackexchange.com/a/414010 > On Oct 2, 2023, at 3:28 PM, Lonnie Abelbeck <li...@lo...> wrote: > > Added. > > https://github.com/astlinux-project/astlinux/commit/3bbd0980010ea3b2cb4f16b6a42010302c2fdbff > > Lonnie > > >> On Oct 1, 2023, at 7:07 PM, Michael Knill <mic...@ip...> wrote: >> >> Thanks guys for this. >> >> Yes I fully understand your first comment Lonnie. We have this problem already as we replace lighttpd.conf and sshd.conf so whenever we do an OS upgrade we check these for changes and merge accordingly. >> >> So we will do it this way for now until we build our own image or you add the rc.conf variable. Note that there are probably other init scripts we will change anyway so this is not a deal breaker currently but if its easy to do then yes Im all for it! >> >> Regards >> Michael Knill >> >> >> From: Michael Keuter <li...@mk...> >> Date: Sunday, 1 October 2023 at 10:57 pm >> To: AstLinux Developers Mailing List <ast...@li...> >> Subject: Re: [Astlinux-devel] [Astlinux-users] Stopping logging of Crontab >> >> Hi Lonnie, >> >> OK, "CRON_LOG_METHOD" sounds good to me. >> It depends what you do with the system, for most people this might be irrelevant. >> >> Michael (AU), what do you think? >> >> Michael >> >>> Am 30.09.2023 um 14:10 schrieb Lonnie Abelbeck <li...@lo...>: >>> >>> Hi Michael (DE), >>> >>> Logging only errors is not an option AFAIK. The default crond log level is 8, which is the least verbose. >>> >>> I briefly considered a rc.conf variable, something like: >>> -- >>> ## CRON Daemon >>> #CRON_LOG_METHOD="none" # Log Methods: "syslog", "file" (/var/log/cron.log), or "none". Default is "syslog" >>> -- >>> Additionally, logrotate would need to rotate /var/log/cron.log if it exists. >>> >>> Then I questioned whether it would be worth the trouble? >>> >>> Lonnie >>> >>>> On Sep 30, 2023, at 5:37 AM, Michael Keuter <li...@mk...> wrote: >>>> >>>> Hi, >>>> >>>> I find that logging also sometimes annoying (so I filter it out for the status tab. >>>> >>>> What about an additional "rc.conf" variable (default is NO): >>>> >>>> CRON_LOG_ERRORS_ONLY=yes >>>> >>>>> Am 30.09.2023 um 03:53 schrieb Lonnie Abelbeck <li...@lo...>: >>>>> >>>>> Hi Michael, >>>>> >>>>> Yes, "building our own image" is the correct way to tweak this. :-) >>>>> >>>>>> • Is it ok to do this? >>>>> >>>>> Not in general, but in this specific case it is probably fine. >>>>> >>>>> If you do the 'sed -i ...' as you stated, you are no longer using the read-only base image '/mnt/asturo/etc/init.d/crond' file, instead you are creating an edited writable '/mnt/asturw/etc/init.d/crond' overlay file. This will work as long as any future base image /etc/init.d/crond file does not have important changes your edited copy would not contain. >>>>> >>>>> The good news for this specific file, it was last changed on "Nov 2, 2015" and is probably not likely to change in the near future. As such, your 'sed -i ...' may be a useable fix until you are building our own image. >>>>> >>>>> Understand that when the day comes and you build an image with the fix, you would need to remove the '/mnt/asturw/etc/init.d/crond' file to see the read-only base image version. >>>>> >>>>>> • Will the changes disappear after an upgrade? >>>>> >>>>> The newly created/edited '/mnt/asturw/etc/init.d/crond' file will be used after any upgrade. >>>>> >>>>> Lonnie >>>>> >>>>>> On Sep 29, 2023, at 7:44 PM, Michael Knill <mic...@ip...> wrote: >>>>>> >>>>>> Hi Lonnie >>>>>> >>>>>> Moving this to the developer list. >>>>>> So as part of our upgrade we will run ‘sed -i 's/^ crond$/ crond -L \/dev\/null/g' /etc/init.d/crond’ which seems to work fine. >>>>>> So my questions are: >>>>>> • Is it ok to do this? >>>>>> • Will the changes disappear after an upgrade? >>>>>> >>>>>> We have decided that moving forward (timeframe unknown) we will be forking the repository and building our own image (finally you say!). >>>>>> We had toyed with the idea of completely rebuilding the system on standard platforms but now want to continue with Astlinux because of its reliability and small footprint. >>>>>> As such, the above will be unnecessary eventually. >>>>>> >>>>>> Regards >>>>>> Michael Knill >>>>>> >>>>>> >>>>>> From: Lonnie Abelbeck <li...@lo...> >>>>>> Date: Friday, 29 September 2023 at 4:43 am >>>>>> To: AstLinux Users Mailing List <ast...@li...> >>>>>> Subject: Re: [Astlinux-users] Stopping logging of Crontab >>>>>> >>>>>> Hi Michael, >>>>>> >>>>>> Looking at the /etc/init.d/crond init script, here [1] >>>>>> >>>>>> If the line "crond" was changed to "crond -L /var/log/crond.log" it would disable syslog and use that file ... but may need rotating if it gets large. >>>>>> >>>>>> If the line "crond" was changed to "crond -L /dev/null" it would disable syslog and disable logging (ie. to /dev/null). >>>>>> >>>>>> BTW, I manually tested both cases to be certain. >>>>>> >>>>>> Lonnie >>>>>> >>>>>> [1] https://github.com/astlinux-project/astlinux/blob/09e87eff8bca82bf4afab8dbe09560737dd80d5c/project/astlinux/target_skeleton/etc/init.d/crond#L38 >>>>>> >>>>>> >>>>>> >>>>>>> On Sep 27, 2023, at 8:01 PM, Michael Knill <mic...@ip...> wrote: >>>>>>> >>>>>>> Hi group >>>>>>> >>>>>>> Replying to this email again. I do understand below but just wondering if there is any way to turn off Cron logging totally or send to a separate log file? >>>>>>> >>>>>>> Regards >>>>>>> Michael Knill >>>>>>> >>>>>>> >>>>>>> From: Lonnie Abelbeck <li...@lo...> >>>>>>> Date: Friday, 31 March 2023 at 1:01 am >>>>>>> To: AstLinux Users Mailing List <ast...@li...> >>>>>>> Subject: Re: [Astlinux-users] Stopping logging of Crontab >>>>>>> >>>>>>> Hi Michael, >>>>>>> >>>>>>> The (busybox) crond daemon has a syslog level setting which defaults to 8, the least verbose log level. So no help there. >>>>>>> >>>>>>> Using the filter for the Status Tab, is a reasonable idea. >>>>>>> >>>>>>> >>>>>>> Personally, when executing shell commands on a regular interval of seconds/minutes, I prefer to use a bash shell script and the sleep builtin. (Using the sleep builtin keeps from spawning a new process whenever 'sleep' is called). >>>>>>> >>>>>>> The simplest example of this is the 'msmtpqueue' bash script [1] >>>>>>> >>>>>>> Basic code setup and loop: >>>>>>> -- >>>>>>> #!/bin/bash >>>>>>> >>>>>>> LOCKFILE="/var/lock/foobar.lock" >>>>>>> >>>>>>> # Robust 'bash' method of creating/testing for a lockfile >>>>>>> if ! ( set -o noclobber; echo "$$" > "$LOCKFILE" ) 2>/dev/null; then >>>>>>> echo "foobar: already running, lockfile \"$LOCKFILE\" exists, process id: $(cat "$LOCKFILE")." >>>>>>> return 9 >>>>>>> fi >>>>>>> >>>>>>> # Load 'sleep' builtin if it exists >>>>>>> if [ -f /usr/lib/bash/sleep ]; then >>>>>>> enable -f /usr/lib/bash/sleep sleep >>>>>>> fi >>>>>>> >>>>>>> #seconds to wait >>>>>>> wait=300 >>>>>>> >>>>>>> trap 'rm -f "$LOCKFILE"; exit $?' INT TERM EXIT >>>>>>> >>>>>>> while true; do >>>>>>> # do stuff >>>>>>> >>>>>>> sleep $wait >>>>>>> done >>>>>>> >>>>>>> rm -f "$LOCKFILE" >>>>>>> trap - INT TERM EXIT >>>>>>> -- >>>>>>> >>>>>>> Look at the actual code [1] for finer details. Another fairly simple example, asterisk-sip-monitor [2] which adds a PID file that can be removed to exit the script. >>>>>>> >>>>>>> Lonnie >>>>>>> >>>>>>> [1] https://github.com/astlinux-project/astlinux/blob/master/package/msmtp/msmtpqueue.sh >>>>>>> >>>>>>> [2] https://github.com/astlinux-project/astlinux/blob/master/package/asterisk/asterisk-sip-monitor >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Mar 29, 2023, at 11:39 PM, Michael Knill <mic...@ip...> wrote: >>>>>>>> >>>>>>>> Short of putting in a filter for the Status Tab, is there any way to stop Crontab logging to Syslog. >>>>>>>> I now have a process that is run every 10 minutes and its annoying that it logs to Syslog each time. >>>>>>>> >>>>>>>> Regards >>>>>>>> >>>>>>>> Michael Knill >>>>>>>> Managing Director >> >> >> >> >> >> >> _______________________________________________ >> Astlinux-devel mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >> _______________________________________________ >> Astlinux-devel mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel _______________________________________________ Astlinux-devel mailing list Ast...@li... https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: Lonnie A. <li...@lo...> - 2023-10-03 20:13:53
|
Update. It seems Michael (DE) was correct to whether a crond log-level existed for "error" logging and not "info" logging. Commit here [1] While the busybox crond only talks about a least verbose (default) level of "8", looking at the code a level of "9" can be used to ignore the "info" logs and only log "error" logs. Quite a few github projects use "crond -l 9" to get "error" only logs for syslog. More info here [2] Michael (AU), while using "crond -L /dev/null" is a valid way to ignore all logs, "crond -l 9" may be better in general to show crontab syntax errors. -- ## Cron Daemon #CRON_LOG_METHOD="file" # Log Methods: "syslog", "file" (/var/log/cron.log), or "none". Default is "syslog" #CRON_LOG_LEVEL="error" # Log Levels: "info" or "error". Default is "info" -- Lonnie [1] https://github.com/astlinux-project/astlinux/commit/3aaf769d50bc656ecfe3375ec7e93b3ba0c77375 [2] https://unix.stackexchange.com/a/414010 > On Oct 2, 2023, at 3:28 PM, Lonnie Abelbeck <li...@lo...> wrote: > > Added. > > https://github.com/astlinux-project/astlinux/commit/3bbd0980010ea3b2cb4f16b6a42010302c2fdbff > > Lonnie > > >> On Oct 1, 2023, at 7:07 PM, Michael Knill <mic...@ip...> wrote: >> >> Thanks guys for this. >> >> Yes I fully understand your first comment Lonnie. We have this problem already as we replace lighttpd.conf and sshd.conf so whenever we do an OS upgrade we check these for changes and merge accordingly. >> >> So we will do it this way for now until we build our own image or you add the rc.conf variable. Note that there are probably other init scripts we will change anyway so this is not a deal breaker currently but if its easy to do then yes Im all for it! >> >> Regards >> Michael Knill >> >> >> From: Michael Keuter <li...@mk...> >> Date: Sunday, 1 October 2023 at 10:57 pm >> To: AstLinux Developers Mailing List <ast...@li...> >> Subject: Re: [Astlinux-devel] [Astlinux-users] Stopping logging of Crontab >> >> Hi Lonnie, >> >> OK, "CRON_LOG_METHOD" sounds good to me. >> It depends what you do with the system, for most people this might be irrelevant. >> >> Michael (AU), what do you think? >> >> Michael >> >>> Am 30.09.2023 um 14:10 schrieb Lonnie Abelbeck <li...@lo...>: >>> >>> Hi Michael (DE), >>> >>> Logging only errors is not an option AFAIK. The default crond log level is 8, which is the least verbose. >>> >>> I briefly considered a rc.conf variable, something like: >>> -- >>> ## CRON Daemon >>> #CRON_LOG_METHOD="none" # Log Methods: "syslog", "file" (/var/log/cron.log), or "none". Default is "syslog" >>> -- >>> Additionally, logrotate would need to rotate /var/log/cron.log if it exists. >>> >>> Then I questioned whether it would be worth the trouble? >>> >>> Lonnie >>> >>>> On Sep 30, 2023, at 5:37 AM, Michael Keuter <li...@mk...> wrote: >>>> >>>> Hi, >>>> >>>> I find that logging also sometimes annoying (so I filter it out for the status tab. >>>> >>>> What about an additional "rc.conf" variable (default is NO): >>>> >>>> CRON_LOG_ERRORS_ONLY=yes >>>> >>>>> Am 30.09.2023 um 03:53 schrieb Lonnie Abelbeck <li...@lo...>: >>>>> >>>>> Hi Michael, >>>>> >>>>> Yes, "building our own image" is the correct way to tweak this. :-) >>>>> >>>>>> • Is it ok to do this? >>>>> >>>>> Not in general, but in this specific case it is probably fine. >>>>> >>>>> If you do the 'sed -i ...' as you stated, you are no longer using the read-only base image '/mnt/asturo/etc/init.d/crond' file, instead you are creating an edited writable '/mnt/asturw/etc/init.d/crond' overlay file. This will work as long as any future base image /etc/init.d/crond file does not have important changes your edited copy would not contain. >>>>> >>>>> The good news for this specific file, it was last changed on "Nov 2, 2015" and is probably not likely to change in the near future. As such, your 'sed -i ...' may be a useable fix until you are building our own image. >>>>> >>>>> Understand that when the day comes and you build an image with the fix, you would need to remove the '/mnt/asturw/etc/init.d/crond' file to see the read-only base image version. >>>>> >>>>>> • Will the changes disappear after an upgrade? >>>>> >>>>> The newly created/edited '/mnt/asturw/etc/init.d/crond' file will be used after any upgrade. >>>>> >>>>> Lonnie >>>>> >>>>>> On Sep 29, 2023, at 7:44 PM, Michael Knill <mic...@ip...> wrote: >>>>>> >>>>>> Hi Lonnie >>>>>> >>>>>> Moving this to the developer list. >>>>>> So as part of our upgrade we will run ‘sed -i 's/^ crond$/ crond -L \/dev\/null/g' /etc/init.d/crond’ which seems to work fine. >>>>>> So my questions are: >>>>>> • Is it ok to do this? >>>>>> • Will the changes disappear after an upgrade? >>>>>> >>>>>> We have decided that moving forward (timeframe unknown) we will be forking the repository and building our own image (finally you say!). >>>>>> We had toyed with the idea of completely rebuilding the system on standard platforms but now want to continue with Astlinux because of its reliability and small footprint. >>>>>> As such, the above will be unnecessary eventually. >>>>>> >>>>>> Regards >>>>>> Michael Knill >>>>>> >>>>>> >>>>>> From: Lonnie Abelbeck <li...@lo...> >>>>>> Date: Friday, 29 September 2023 at 4:43 am >>>>>> To: AstLinux Users Mailing List <ast...@li...> >>>>>> Subject: Re: [Astlinux-users] Stopping logging of Crontab >>>>>> >>>>>> Hi Michael, >>>>>> >>>>>> Looking at the /etc/init.d/crond init script, here [1] >>>>>> >>>>>> If the line "crond" was changed to "crond -L /var/log/crond.log" it would disable syslog and use that file ... but may need rotating if it gets large. >>>>>> >>>>>> If the line "crond" was changed to "crond -L /dev/null" it would disable syslog and disable logging (ie. to /dev/null). >>>>>> >>>>>> BTW, I manually tested both cases to be certain. >>>>>> >>>>>> Lonnie >>>>>> >>>>>> [1] https://github.com/astlinux-project/astlinux/blob/09e87eff8bca82bf4afab8dbe09560737dd80d5c/project/astlinux/target_skeleton/etc/init.d/crond#L38 >>>>>> >>>>>> >>>>>> >>>>>>> On Sep 27, 2023, at 8:01 PM, Michael Knill <mic...@ip...> wrote: >>>>>>> >>>>>>> Hi group >>>>>>> >>>>>>> Replying to this email again. I do understand below but just wondering if there is any way to turn off Cron logging totally or send to a separate log file? >>>>>>> >>>>>>> Regards >>>>>>> Michael Knill >>>>>>> >>>>>>> >>>>>>> From: Lonnie Abelbeck <li...@lo...> >>>>>>> Date: Friday, 31 March 2023 at 1:01 am >>>>>>> To: AstLinux Users Mailing List <ast...@li...> >>>>>>> Subject: Re: [Astlinux-users] Stopping logging of Crontab >>>>>>> >>>>>>> Hi Michael, >>>>>>> >>>>>>> The (busybox) crond daemon has a syslog level setting which defaults to 8, the least verbose log level. So no help there. >>>>>>> >>>>>>> Using the filter for the Status Tab, is a reasonable idea. >>>>>>> >>>>>>> >>>>>>> Personally, when executing shell commands on a regular interval of seconds/minutes, I prefer to use a bash shell script and the sleep builtin. (Using the sleep builtin keeps from spawning a new process whenever 'sleep' is called). >>>>>>> >>>>>>> The simplest example of this is the 'msmtpqueue' bash script [1] >>>>>>> >>>>>>> Basic code setup and loop: >>>>>>> -- >>>>>>> #!/bin/bash >>>>>>> >>>>>>> LOCKFILE="/var/lock/foobar.lock" >>>>>>> >>>>>>> # Robust 'bash' method of creating/testing for a lockfile >>>>>>> if ! ( set -o noclobber; echo "$$" > "$LOCKFILE" ) 2>/dev/null; then >>>>>>> echo "foobar: already running, lockfile \"$LOCKFILE\" exists, process id: $(cat "$LOCKFILE")." >>>>>>> return 9 >>>>>>> fi >>>>>>> >>>>>>> # Load 'sleep' builtin if it exists >>>>>>> if [ -f /usr/lib/bash/sleep ]; then >>>>>>> enable -f /usr/lib/bash/sleep sleep >>>>>>> fi >>>>>>> >>>>>>> #seconds to wait >>>>>>> wait=300 >>>>>>> >>>>>>> trap 'rm -f "$LOCKFILE"; exit $?' INT TERM EXIT >>>>>>> >>>>>>> while true; do >>>>>>> # do stuff >>>>>>> >>>>>>> sleep $wait >>>>>>> done >>>>>>> >>>>>>> rm -f "$LOCKFILE" >>>>>>> trap - INT TERM EXIT >>>>>>> -- >>>>>>> >>>>>>> Look at the actual code [1] for finer details. Another fairly simple example, asterisk-sip-monitor [2] which adds a PID file that can be removed to exit the script. >>>>>>> >>>>>>> Lonnie >>>>>>> >>>>>>> [1] https://github.com/astlinux-project/astlinux/blob/master/package/msmtp/msmtpqueue.sh >>>>>>> >>>>>>> [2] https://github.com/astlinux-project/astlinux/blob/master/package/asterisk/asterisk-sip-monitor >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Mar 29, 2023, at 11:39 PM, Michael Knill <mic...@ip...> wrote: >>>>>>>> >>>>>>>> Short of putting in a filter for the Status Tab, is there any way to stop Crontab logging to Syslog. >>>>>>>> I now have a process that is run every 10 minutes and its annoying that it logs to Syslog each time. >>>>>>>> >>>>>>>> Regards >>>>>>>> >>>>>>>> Michael Knill >>>>>>>> Managing Director >> >> >> >> >> >> >> _______________________________________________ >> Astlinux-devel mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >> _______________________________________________ >> Astlinux-devel mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: Lonnie A. <li...@lo...> - 2023-10-02 20:29:09
|
Added. https://github.com/astlinux-project/astlinux/commit/3bbd0980010ea3b2cb4f16b6a42010302c2fdbff Lonnie > On Oct 1, 2023, at 7:07 PM, Michael Knill <mic...@ip...> wrote: > > Thanks guys for this. > > Yes I fully understand your first comment Lonnie. We have this problem already as we replace lighttpd.conf and sshd.conf so whenever we do an OS upgrade we check these for changes and merge accordingly. > > So we will do it this way for now until we build our own image or you add the rc.conf variable. Note that there are probably other init scripts we will change anyway so this is not a deal breaker currently but if its easy to do then yes Im all for it! > > Regards > Michael Knill > > > From: Michael Keuter <li...@mk...> > Date: Sunday, 1 October 2023 at 10:57 pm > To: AstLinux Developers Mailing List <ast...@li...> > Subject: Re: [Astlinux-devel] [Astlinux-users] Stopping logging of Crontab > > Hi Lonnie, > > OK, "CRON_LOG_METHOD" sounds good to me. > It depends what you do with the system, for most people this might be irrelevant. > > Michael (AU), what do you think? > > Michael > > > Am 30.09.2023 um 14:10 schrieb Lonnie Abelbeck <li...@lo...>: > > > > Hi Michael (DE), > > > > Logging only errors is not an option AFAIK. The default crond log level is 8, which is the least verbose. > > > > I briefly considered a rc.conf variable, something like: > > -- > > ## CRON Daemon > > #CRON_LOG_METHOD="none" # Log Methods: "syslog", "file" (/var/log/cron.log), or "none". Default is "syslog" > > -- > > Additionally, logrotate would need to rotate /var/log/cron.log if it exists. > > > > Then I questioned whether it would be worth the trouble? > > > > Lonnie > > > >> On Sep 30, 2023, at 5:37 AM, Michael Keuter <li...@mk...> wrote: > >> > >> Hi, > >> > >> I find that logging also sometimes annoying (so I filter it out for the status tab. > >> > >> What about an additional "rc.conf" variable (default is NO): > >> > >> CRON_LOG_ERRORS_ONLY=yes > >> > >>> Am 30.09.2023 um 03:53 schrieb Lonnie Abelbeck <li...@lo...>: > >>> > >>> Hi Michael, > >>> > >>> Yes, "building our own image" is the correct way to tweak this. :-) > >>> > >>>> • Is it ok to do this? > >>> > >>> Not in general, but in this specific case it is probably fine. > >>> > >>> If you do the 'sed -i ...' as you stated, you are no longer using the read-only base image '/mnt/asturo/etc/init.d/crond' file, instead you are creating an edited writable '/mnt/asturw/etc/init.d/crond' overlay file. This will work as long as any future base image /etc/init.d/crond file does not have important changes your edited copy would not contain. > >>> > >>> The good news for this specific file, it was last changed on "Nov 2, 2015" and is probably not likely to change in the near future. As such, your 'sed -i ...' may be a useable fix until you are building our own image. > >>> > >>> Understand that when the day comes and you build an image with the fix, you would need to remove the '/mnt/asturw/etc/init.d/crond' file to see the read-only base image version. > >>> > >>>> • Will the changes disappear after an upgrade? > >>> > >>> The newly created/edited '/mnt/asturw/etc/init.d/crond' file will be used after any upgrade. > >>> > >>> Lonnie > >>> > >>>> On Sep 29, 2023, at 7:44 PM, Michael Knill <mic...@ip...> wrote: > >>>> > >>>> Hi Lonnie > >>>> > >>>> Moving this to the developer list. > >>>> So as part of our upgrade we will run ‘sed -i 's/^ crond$/ crond -L \/dev\/null/g' /etc/init.d/crond’ which seems to work fine. > >>>> So my questions are: > >>>> • Is it ok to do this? > >>>> • Will the changes disappear after an upgrade? > >>>> > >>>> We have decided that moving forward (timeframe unknown) we will be forking the repository and building our own image (finally you say!). > >>>> We had toyed with the idea of completely rebuilding the system on standard platforms but now want to continue with Astlinux because of its reliability and small footprint. > >>>> As such, the above will be unnecessary eventually. > >>>> > >>>> Regards > >>>> Michael Knill > >>>> > >>>> > >>>> From: Lonnie Abelbeck <li...@lo...> > >>>> Date: Friday, 29 September 2023 at 4:43 am > >>>> To: AstLinux Users Mailing List <ast...@li...> > >>>> Subject: Re: [Astlinux-users] Stopping logging of Crontab > >>>> > >>>> Hi Michael, > >>>> > >>>> Looking at the /etc/init.d/crond init script, here [1] > >>>> > >>>> If the line "crond" was changed to "crond -L /var/log/crond.log" it would disable syslog and use that file ... but may need rotating if it gets large. > >>>> > >>>> If the line "crond" was changed to "crond -L /dev/null" it would disable syslog and disable logging (ie. to /dev/null). > >>>> > >>>> BTW, I manually tested both cases to be certain. > >>>> > >>>> Lonnie > >>>> > >>>> [1] https://github.com/astlinux-project/astlinux/blob/09e87eff8bca82bf4afab8dbe09560737dd80d5c/project/astlinux/target_skeleton/etc/init.d/crond#L38 > >>>> > >>>> > >>>> > >>>>> On Sep 27, 2023, at 8:01 PM, Michael Knill <mic...@ip...> wrote: > >>>>> > >>>>> Hi group > >>>>> > >>>>> Replying to this email again. I do understand below but just wondering if there is any way to turn off Cron logging totally or send to a separate log file? > >>>>> > >>>>> Regards > >>>>> Michael Knill > >>>>> > >>>>> > >>>>> From: Lonnie Abelbeck <li...@lo...> > >>>>> Date: Friday, 31 March 2023 at 1:01 am > >>>>> To: AstLinux Users Mailing List <ast...@li...> > >>>>> Subject: Re: [Astlinux-users] Stopping logging of Crontab > >>>>> > >>>>> Hi Michael, > >>>>> > >>>>> The (busybox) crond daemon has a syslog level setting which defaults to 8, the least verbose log level. So no help there. > >>>>> > >>>>> Using the filter for the Status Tab, is a reasonable idea. > >>>>> > >>>>> > >>>>> Personally, when executing shell commands on a regular interval of seconds/minutes, I prefer to use a bash shell script and the sleep builtin. (Using the sleep builtin keeps from spawning a new process whenever 'sleep' is called). > >>>>> > >>>>> The simplest example of this is the 'msmtpqueue' bash script [1] > >>>>> > >>>>> Basic code setup and loop: > >>>>> -- > >>>>> #!/bin/bash > >>>>> > >>>>> LOCKFILE="/var/lock/foobar.lock" > >>>>> > >>>>> # Robust 'bash' method of creating/testing for a lockfile > >>>>> if ! ( set -o noclobber; echo "$$" > "$LOCKFILE" ) 2>/dev/null; then > >>>>> echo "foobar: already running, lockfile \"$LOCKFILE\" exists, process id: $(cat "$LOCKFILE")." > >>>>> return 9 > >>>>> fi > >>>>> > >>>>> # Load 'sleep' builtin if it exists > >>>>> if [ -f /usr/lib/bash/sleep ]; then > >>>>> enable -f /usr/lib/bash/sleep sleep > >>>>> fi > >>>>> > >>>>> #seconds to wait > >>>>> wait=300 > >>>>> > >>>>> trap 'rm -f "$LOCKFILE"; exit $?' INT TERM EXIT > >>>>> > >>>>> while true; do > >>>>> # do stuff > >>>>> > >>>>> sleep $wait > >>>>> done > >>>>> > >>>>> rm -f "$LOCKFILE" > >>>>> trap - INT TERM EXIT > >>>>> -- > >>>>> > >>>>> Look at the actual code [1] for finer details. Another fairly simple example, asterisk-sip-monitor [2] which adds a PID file that can be removed to exit the script. > >>>>> > >>>>> Lonnie > >>>>> > >>>>> [1] https://github.com/astlinux-project/astlinux/blob/master/package/msmtp/msmtpqueue.sh > >>>>> > >>>>> [2] https://github.com/astlinux-project/astlinux/blob/master/package/asterisk/asterisk-sip-monitor > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> On Mar 29, 2023, at 11:39 PM, Michael Knill <mic...@ip...> wrote: > >>>>>> > >>>>>> Short of putting in a filter for the Status Tab, is there any way to stop Crontab logging to Syslog. > >>>>>> I now have a process that is run every 10 minutes and its annoying that it logs to Syslog each time. > >>>>>> > >>>>>> Regards > >>>>>> > >>>>>> Michael Knill > >>>>>> Managing Director > > > > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: Michael K. <mic...@ip...> - 2023-10-02 00:07:47
|
Thanks guys for this. Yes I fully understand your first comment Lonnie. We have this problem already as we replace lighttpd.conf and sshd.conf so whenever we do an OS upgrade we check these for changes and merge accordingly. So we will do it this way for now until we build our own image or you add the rc.conf variable. Note that there are probably other init scripts we will change anyway so this is not a deal breaker currently but if its easy to do then yes Im all for it! Regards Michael Knill From: Michael Keuter <li...@mk...> Date: Sunday, 1 October 2023 at 10:57 pm To: AstLinux Developers Mailing List <ast...@li...> Subject: Re: [Astlinux-devel] [Astlinux-users] Stopping logging of Crontab Hi Lonnie, OK, "CRON_LOG_METHOD" sounds good to me. It depends what you do with the system, for most people this might be irrelevant. Michael (AU), what do you think? Michael > Am 30.09.2023 um 14:10 schrieb Lonnie Abelbeck <li...@lo...>: > > Hi Michael (DE), > > Logging only errors is not an option AFAIK. The default crond log level is 8, which is the least verbose. > > I briefly considered a rc.conf variable, something like: > -- > ## CRON Daemon > #CRON_LOG_METHOD="none" # Log Methods: "syslog", "file" (/var/log/cron.log), or "none". Default is "syslog" > -- > Additionally, logrotate would need to rotate /var/log/cron.log if it exists. > > Then I questioned whether it would be worth the trouble? > > Lonnie > >> On Sep 30, 2023, at 5:37 AM, Michael Keuter <li...@mk...> wrote: >> >> Hi, >> >> I find that logging also sometimes annoying (so I filter it out for the status tab. >> >> What about an additional "rc.conf" variable (default is NO): >> >> CRON_LOG_ERRORS_ONLY=yes >> >>> Am 30.09.2023 um 03:53 schrieb Lonnie Abelbeck <li...@lo...>: >>> >>> Hi Michael, >>> >>> Yes, "building our own image" is the correct way to tweak this. :-) >>> >>>> • Is it ok to do this? >>> >>> Not in general, but in this specific case it is probably fine. >>> >>> If you do the 'sed -i ...' as you stated, you are no longer using the read-only base image '/mnt/asturo/etc/init.d/crond' file, instead you are creating an edited writable '/mnt/asturw/etc/init.d/crond' overlay file. This will work as long as any future base image /etc/init.d/crond file does not have important changes your edited copy would not contain. >>> >>> The good news for this specific file, it was last changed on "Nov 2, 2015" and is probably not likely to change in the near future. As such, your 'sed -i ...' may be a useable fix until you are building our own image. >>> >>> Understand that when the day comes and you build an image with the fix, you would need to remove the '/mnt/asturw/etc/init.d/crond' file to see the read-only base image version. >>> >>>> • Will the changes disappear after an upgrade? >>> >>> The newly created/edited '/mnt/asturw/etc/init.d/crond' file will be used after any upgrade. >>> >>> Lonnie >>> >>>> On Sep 29, 2023, at 7:44 PM, Michael Knill <mic...@ip...> wrote: >>>> >>>> Hi Lonnie >>>> >>>> Moving this to the developer list. >>>> So as part of our upgrade we will run ‘sed -i 's/^ crond$/ crond -L \/dev\/null/g' /etc/init.d/crond’ which seems to work fine. >>>> So my questions are: >>>> • Is it ok to do this? >>>> • Will the changes disappear after an upgrade? >>>> >>>> We have decided that moving forward (timeframe unknown) we will be forking the repository and building our own image (finally you say!). >>>> We had toyed with the idea of completely rebuilding the system on standard platforms but now want to continue with Astlinux because of its reliability and small footprint. >>>> As such, the above will be unnecessary eventually. >>>> >>>> Regards >>>> Michael Knill >>>> >>>> >>>> From: Lonnie Abelbeck <li...@lo...> >>>> Date: Friday, 29 September 2023 at 4:43 am >>>> To: AstLinux Users Mailing List <ast...@li...> >>>> Subject: Re: [Astlinux-users] Stopping logging of Crontab >>>> >>>> Hi Michael, >>>> >>>> Looking at the /etc/init.d/crond init script, here [1] >>>> >>>> If the line "crond" was changed to "crond -L /var/log/crond.log" it would disable syslog and use that file ... but may need rotating if it gets large. >>>> >>>> If the line "crond" was changed to "crond -L /dev/null" it would disable syslog and disable logging (ie. to /dev/null). >>>> >>>> BTW, I manually tested both cases to be certain. >>>> >>>> Lonnie >>>> >>>> [1] https://github.com/astlinux-project/astlinux/blob/09e87eff8bca82bf4afab8dbe09560737dd80d5c/project/astlinux/target_skeleton/etc/init.d/crond#L38 >>>> >>>> >>>> >>>>> On Sep 27, 2023, at 8:01 PM, Michael Knill <mic...@ip...> wrote: >>>>> >>>>> Hi group >>>>> >>>>> Replying to this email again. I do understand below but just wondering if there is any way to turn off Cron logging totally or send to a separate log file? >>>>> >>>>> Regards >>>>> Michael Knill >>>>> >>>>> >>>>> From: Lonnie Abelbeck <li...@lo...> >>>>> Date: Friday, 31 March 2023 at 1:01 am >>>>> To: AstLinux Users Mailing List <ast...@li...> >>>>> Subject: Re: [Astlinux-users] Stopping logging of Crontab >>>>> >>>>> Hi Michael, >>>>> >>>>> The (busybox) crond daemon has a syslog level setting which defaults to 8, the least verbose log level. So no help there. >>>>> >>>>> Using the filter for the Status Tab, is a reasonable idea. >>>>> >>>>> >>>>> Personally, when executing shell commands on a regular interval of seconds/minutes, I prefer to use a bash shell script and the sleep builtin. (Using the sleep builtin keeps from spawning a new process whenever 'sleep' is called). >>>>> >>>>> The simplest example of this is the 'msmtpqueue' bash script [1] >>>>> >>>>> Basic code setup and loop: >>>>> -- >>>>> #!/bin/bash >>>>> >>>>> LOCKFILE="/var/lock/foobar.lock" >>>>> >>>>> # Robust 'bash' method of creating/testing for a lockfile >>>>> if ! ( set -o noclobber; echo "$$" > "$LOCKFILE" ) 2>/dev/null; then >>>>> echo "foobar: already running, lockfile \"$LOCKFILE\" exists, process id: $(cat "$LOCKFILE")." >>>>> return 9 >>>>> fi >>>>> >>>>> # Load 'sleep' builtin if it exists >>>>> if [ -f /usr/lib/bash/sleep ]; then >>>>> enable -f /usr/lib/bash/sleep sleep >>>>> fi >>>>> >>>>> #seconds to wait >>>>> wait=300 >>>>> >>>>> trap 'rm -f "$LOCKFILE"; exit $?' INT TERM EXIT >>>>> >>>>> while true; do >>>>> # do stuff >>>>> >>>>> sleep $wait >>>>> done >>>>> >>>>> rm -f "$LOCKFILE" >>>>> trap - INT TERM EXIT >>>>> -- >>>>> >>>>> Look at the actual code [1] for finer details. Another fairly simple example, asterisk-sip-monitor [2] which adds a PID file that can be removed to exit the script. >>>>> >>>>> Lonnie >>>>> >>>>> [1] https://github.com/astlinux-project/astlinux/blob/master/package/msmtp/msmtpqueue.sh >>>>> >>>>> [2] https://github.com/astlinux-project/astlinux/blob/master/package/asterisk/asterisk-sip-monitor >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> On Mar 29, 2023, at 11:39 PM, Michael Knill <mic...@ip...> wrote: >>>>>> >>>>>> Short of putting in a filter for the Status Tab, is there any way to stop Crontab logging to Syslog. >>>>>> I now have a process that is run every 10 minutes and its annoying that it logs to Syslog each time. >>>>>> >>>>>> Regards >>>>>> >>>>>> Michael Knill >>>>>> Managing Director _______________________________________________ Astlinux-devel mailing list Ast...@li... https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: Michael K. <li...@mk...> - 2023-10-01 11:57:16
|
Hi Lonnie, OK, "CRON_LOG_METHOD" sounds good to me. It depends what you do with the system, for most people this might be irrelevant. Michael (AU), what do you think? Michael > Am 30.09.2023 um 14:10 schrieb Lonnie Abelbeck <li...@lo...>: > > Hi Michael (DE), > > Logging only errors is not an option AFAIK. The default crond log level is 8, which is the least verbose. > > I briefly considered a rc.conf variable, something like: > -- > ## CRON Daemon > #CRON_LOG_METHOD="none" # Log Methods: "syslog", "file" (/var/log/cron.log), or "none". Default is "syslog" > -- > Additionally, logrotate would need to rotate /var/log/cron.log if it exists. > > Then I questioned whether it would be worth the trouble? > > Lonnie > >> On Sep 30, 2023, at 5:37 AM, Michael Keuter <li...@mk...> wrote: >> >> Hi, >> >> I find that logging also sometimes annoying (so I filter it out for the status tab. >> >> What about an additional "rc.conf" variable (default is NO): >> >> CRON_LOG_ERRORS_ONLY=yes >> >>> Am 30.09.2023 um 03:53 schrieb Lonnie Abelbeck <li...@lo...>: >>> >>> Hi Michael, >>> >>> Yes, "building our own image" is the correct way to tweak this. :-) >>> >>>> • Is it ok to do this? >>> >>> Not in general, but in this specific case it is probably fine. >>> >>> If you do the 'sed -i ...' as you stated, you are no longer using the read-only base image '/mnt/asturo/etc/init.d/crond' file, instead you are creating an edited writable '/mnt/asturw/etc/init.d/crond' overlay file. This will work as long as any future base image /etc/init.d/crond file does not have important changes your edited copy would not contain. >>> >>> The good news for this specific file, it was last changed on "Nov 2, 2015" and is probably not likely to change in the near future. As such, your 'sed -i ...' may be a useable fix until you are building our own image. >>> >>> Understand that when the day comes and you build an image with the fix, you would need to remove the '/mnt/asturw/etc/init.d/crond' file to see the read-only base image version. >>> >>>> • Will the changes disappear after an upgrade? >>> >>> The newly created/edited '/mnt/asturw/etc/init.d/crond' file will be used after any upgrade. >>> >>> Lonnie >>> >>>> On Sep 29, 2023, at 7:44 PM, Michael Knill <mic...@ip...> wrote: >>>> >>>> Hi Lonnie >>>> >>>> Moving this to the developer list. >>>> So as part of our upgrade we will run ‘sed -i 's/^ crond$/ crond -L \/dev\/null/g' /etc/init.d/crond’ which seems to work fine. >>>> So my questions are: >>>> • Is it ok to do this? >>>> • Will the changes disappear after an upgrade? >>>> >>>> We have decided that moving forward (timeframe unknown) we will be forking the repository and building our own image (finally you say!). >>>> We had toyed with the idea of completely rebuilding the system on standard platforms but now want to continue with Astlinux because of its reliability and small footprint. >>>> As such, the above will be unnecessary eventually. >>>> >>>> Regards >>>> Michael Knill >>>> >>>> >>>> From: Lonnie Abelbeck <li...@lo...> >>>> Date: Friday, 29 September 2023 at 4:43 am >>>> To: AstLinux Users Mailing List <ast...@li...> >>>> Subject: Re: [Astlinux-users] Stopping logging of Crontab >>>> >>>> Hi Michael, >>>> >>>> Looking at the /etc/init.d/crond init script, here [1] >>>> >>>> If the line "crond" was changed to "crond -L /var/log/crond.log" it would disable syslog and use that file ... but may need rotating if it gets large. >>>> >>>> If the line "crond" was changed to "crond -L /dev/null" it would disable syslog and disable logging (ie. to /dev/null). >>>> >>>> BTW, I manually tested both cases to be certain. >>>> >>>> Lonnie >>>> >>>> [1] https://github.com/astlinux-project/astlinux/blob/09e87eff8bca82bf4afab8dbe09560737dd80d5c/project/astlinux/target_skeleton/etc/init.d/crond#L38 >>>> >>>> >>>> >>>>> On Sep 27, 2023, at 8:01 PM, Michael Knill <mic...@ip...> wrote: >>>>> >>>>> Hi group >>>>> >>>>> Replying to this email again. I do understand below but just wondering if there is any way to turn off Cron logging totally or send to a separate log file? >>>>> >>>>> Regards >>>>> Michael Knill >>>>> >>>>> >>>>> From: Lonnie Abelbeck <li...@lo...> >>>>> Date: Friday, 31 March 2023 at 1:01 am >>>>> To: AstLinux Users Mailing List <ast...@li...> >>>>> Subject: Re: [Astlinux-users] Stopping logging of Crontab >>>>> >>>>> Hi Michael, >>>>> >>>>> The (busybox) crond daemon has a syslog level setting which defaults to 8, the least verbose log level. So no help there. >>>>> >>>>> Using the filter for the Status Tab, is a reasonable idea. >>>>> >>>>> >>>>> Personally, when executing shell commands on a regular interval of seconds/minutes, I prefer to use a bash shell script and the sleep builtin. (Using the sleep builtin keeps from spawning a new process whenever 'sleep' is called). >>>>> >>>>> The simplest example of this is the 'msmtpqueue' bash script [1] >>>>> >>>>> Basic code setup and loop: >>>>> -- >>>>> #!/bin/bash >>>>> >>>>> LOCKFILE="/var/lock/foobar.lock" >>>>> >>>>> # Robust 'bash' method of creating/testing for a lockfile >>>>> if ! ( set -o noclobber; echo "$$" > "$LOCKFILE" ) 2>/dev/null; then >>>>> echo "foobar: already running, lockfile \"$LOCKFILE\" exists, process id: $(cat "$LOCKFILE")." >>>>> return 9 >>>>> fi >>>>> >>>>> # Load 'sleep' builtin if it exists >>>>> if [ -f /usr/lib/bash/sleep ]; then >>>>> enable -f /usr/lib/bash/sleep sleep >>>>> fi >>>>> >>>>> #seconds to wait >>>>> wait=300 >>>>> >>>>> trap 'rm -f "$LOCKFILE"; exit $?' INT TERM EXIT >>>>> >>>>> while true; do >>>>> # do stuff >>>>> >>>>> sleep $wait >>>>> done >>>>> >>>>> rm -f "$LOCKFILE" >>>>> trap - INT TERM EXIT >>>>> -- >>>>> >>>>> Look at the actual code [1] for finer details. Another fairly simple example, asterisk-sip-monitor [2] which adds a PID file that can be removed to exit the script. >>>>> >>>>> Lonnie >>>>> >>>>> [1] https://github.com/astlinux-project/astlinux/blob/master/package/msmtp/msmtpqueue.sh >>>>> >>>>> [2] https://github.com/astlinux-project/astlinux/blob/master/package/asterisk/asterisk-sip-monitor >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> On Mar 29, 2023, at 11:39 PM, Michael Knill <mic...@ip...> wrote: >>>>>> >>>>>> Short of putting in a filter for the Status Tab, is there any way to stop Crontab logging to Syslog. >>>>>> I now have a process that is run every 10 minutes and its annoying that it logs to Syslog each time. >>>>>> >>>>>> Regards >>>>>> >>>>>> Michael Knill >>>>>> Managing Director |
|
From: Lonnie A. <li...@lo...> - 2023-09-30 12:10:32
|
Hi Michael (DE), Logging only errors is not an option AFAIK. The default crond log level is 8, which is the least verbose. I briefly considered a rc.conf variable, something like: -- ## CRON Daemon #CRON_LOG_METHOD="none" # Log Methods: "syslog", "file" (/var/log/cron.log), or "none". Default is "syslog" -- Additionally, logrotate would need to rotate /var/log/cron.log if it exists. Then I questioned whether it would be worth the trouble? Lonnie > On Sep 30, 2023, at 5:37 AM, Michael Keuter <li...@mk...> wrote: > > Hi, > > I find that logging also sometimes annoying (so I filter it out for the status tab. > > What about an additional "rc.conf" variable (default is NO): > > CRON_LOG_ERRORS_ONLY=yes > >> Am 30.09.2023 um 03:53 schrieb Lonnie Abelbeck <li...@lo...>: >> >> Hi Michael, >> >> Yes, "building our own image" is the correct way to tweak this. :-) >> >>> • Is it ok to do this? >> >> Not in general, but in this specific case it is probably fine. >> >> If you do the 'sed -i ...' as you stated, you are no longer using the read-only base image '/mnt/asturo/etc/init.d/crond' file, instead you are creating an edited writable '/mnt/asturw/etc/init.d/crond' overlay file. This will work as long as any future base image /etc/init.d/crond file does not have important changes your edited copy would not contain. >> >> The good news for this specific file, it was last changed on "Nov 2, 2015" and is probably not likely to change in the near future. As such, your 'sed -i ...' may be a useable fix until you are building our own image. >> >> Understand that when the day comes and you build an image with the fix, you would need to remove the '/mnt/asturw/etc/init.d/crond' file to see the read-only base image version. >> >>> • Will the changes disappear after an upgrade? >> >> The newly created/edited '/mnt/asturw/etc/init.d/crond' file will be used after any upgrade. >> >> Lonnie >> >>> On Sep 29, 2023, at 7:44 PM, Michael Knill <mic...@ip...> wrote: >>> >>> Hi Lonnie >>> >>> Moving this to the developer list. >>> So as part of our upgrade we will run ‘sed -i 's/^ crond$/ crond -L \/dev\/null/g' /etc/init.d/crond’ which seems to work fine. >>> So my questions are: >>> • Is it ok to do this? >>> • Will the changes disappear after an upgrade? >>> >>> We have decided that moving forward (timeframe unknown) we will be forking the repository and building our own image (finally you say!). >>> We had toyed with the idea of completely rebuilding the system on standard platforms but now want to continue with Astlinux because of its reliability and small footprint. >>> As such, the above will be unnecessary eventually. >>> >>> Regards >>> Michael Knill >>> >>> >>> From: Lonnie Abelbeck <li...@lo...> >>> Date: Friday, 29 September 2023 at 4:43 am >>> To: AstLinux Users Mailing List <ast...@li...> >>> Subject: Re: [Astlinux-users] Stopping logging of Crontab >>> >>> Hi Michael, >>> >>> Looking at the /etc/init.d/crond init script, here [1] >>> >>> If the line "crond" was changed to "crond -L /var/log/crond.log" it would disable syslog and use that file ... but may need rotating if it gets large. >>> >>> If the line "crond" was changed to "crond -L /dev/null" it would disable syslog and disable logging (ie. to /dev/null). >>> >>> BTW, I manually tested both cases to be certain. >>> >>> Lonnie >>> >>> [1] https://github.com/astlinux-project/astlinux/blob/09e87eff8bca82bf4afab8dbe09560737dd80d5c/project/astlinux/target_skeleton/etc/init.d/crond#L38 >>> >>> >>> >>>> On Sep 27, 2023, at 8:01 PM, Michael Knill <mic...@ip...> wrote: >>>> >>>> Hi group >>>> >>>> Replying to this email again. I do understand below but just wondering if there is any way to turn off Cron logging totally or send to a separate log file? >>>> >>>> Regards >>>> Michael Knill >>>> >>>> >>>> From: Lonnie Abelbeck <li...@lo...> >>>> Date: Friday, 31 March 2023 at 1:01 am >>>> To: AstLinux Users Mailing List <ast...@li...> >>>> Subject: Re: [Astlinux-users] Stopping logging of Crontab >>>> >>>> Hi Michael, >>>> >>>> The (busybox) crond daemon has a syslog level setting which defaults to 8, the least verbose log level. So no help there. >>>> >>>> Using the filter for the Status Tab, is a reasonable idea. >>>> >>>> >>>> Personally, when executing shell commands on a regular interval of seconds/minutes, I prefer to use a bash shell script and the sleep builtin. (Using the sleep builtin keeps from spawning a new process whenever 'sleep' is called). >>>> >>>> The simplest example of this is the 'msmtpqueue' bash script [1] >>>> >>>> Basic code setup and loop: >>>> -- >>>> #!/bin/bash >>>> >>>> LOCKFILE="/var/lock/foobar.lock" >>>> >>>> # Robust 'bash' method of creating/testing for a lockfile >>>> if ! ( set -o noclobber; echo "$$" > "$LOCKFILE" ) 2>/dev/null; then >>>> echo "foobar: already running, lockfile \"$LOCKFILE\" exists, process id: $(cat "$LOCKFILE")." >>>> return 9 >>>> fi >>>> >>>> # Load 'sleep' builtin if it exists >>>> if [ -f /usr/lib/bash/sleep ]; then >>>> enable -f /usr/lib/bash/sleep sleep >>>> fi >>>> >>>> #seconds to wait >>>> wait=300 >>>> >>>> trap 'rm -f "$LOCKFILE"; exit $?' INT TERM EXIT >>>> >>>> while true; do >>>> # do stuff >>>> >>>> sleep $wait >>>> done >>>> >>>> rm -f "$LOCKFILE" >>>> trap - INT TERM EXIT >>>> -- >>>> >>>> Look at the actual code [1] for finer details. Another fairly simple example, asterisk-sip-monitor [2] which adds a PID file that can be removed to exit the script. >>>> >>>> Lonnie >>>> >>>> [1] https://github.com/astlinux-project/astlinux/blob/master/package/msmtp/msmtpqueue.sh >>>> >>>> [2] https://github.com/astlinux-project/astlinux/blob/master/package/asterisk/asterisk-sip-monitor >>>> >>>> >>>> >>>> >>>> >>>>> On Mar 29, 2023, at 11:39 PM, Michael Knill <mic...@ip...> wrote: >>>>> >>>>> Short of putting in a filter for the Status Tab, is there any way to stop Crontab logging to Syslog. >>>>> I now have a process that is run every 10 minutes and its annoying that it logs to Syslog each time. >>>>> >>>>> Regards >>>>> >>>>> Michael Knill >>>>> Managing Director > > Michael > > http://www.mksolutions.info > > > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: Michael K. <li...@mk...> - 2023-09-30 10:37:45
|
Hi, I find that logging also sometimes annoying (so I filter it out for the status tab. What about an additional "rc.conf" variable (default is NO): CRON_LOG_ERRORS_ONLY=yes > Am 30.09.2023 um 03:53 schrieb Lonnie Abelbeck <li...@lo...>: > > Hi Michael, > > Yes, "building our own image" is the correct way to tweak this. :-) > >> • Is it ok to do this? > > Not in general, but in this specific case it is probably fine. > > If you do the 'sed -i ...' as you stated, you are no longer using the read-only base image '/mnt/asturo/etc/init.d/crond' file, instead you are creating an edited writable '/mnt/asturw/etc/init.d/crond' overlay file. This will work as long as any future base image /etc/init.d/crond file does not have important changes your edited copy would not contain. > > The good news for this specific file, it was last changed on "Nov 2, 2015" and is probably not likely to change in the near future. As such, your 'sed -i ...' may be a useable fix until you are building our own image. > > Understand that when the day comes and you build an image with the fix, you would need to remove the '/mnt/asturw/etc/init.d/crond' file to see the read-only base image version. > >> • Will the changes disappear after an upgrade? > > The newly created/edited '/mnt/asturw/etc/init.d/crond' file will be used after any upgrade. > > Lonnie > >> On Sep 29, 2023, at 7:44 PM, Michael Knill <mic...@ip...> wrote: >> >> Hi Lonnie >> >> Moving this to the developer list. >> So as part of our upgrade we will run ‘sed -i 's/^ crond$/ crond -L \/dev\/null/g' /etc/init.d/crond’ which seems to work fine. >> So my questions are: >> • Is it ok to do this? >> • Will the changes disappear after an upgrade? >> >> We have decided that moving forward (timeframe unknown) we will be forking the repository and building our own image (finally you say!). >> We had toyed with the idea of completely rebuilding the system on standard platforms but now want to continue with Astlinux because of its reliability and small footprint. >> As such, the above will be unnecessary eventually. >> >> Regards >> Michael Knill >> >> >> From: Lonnie Abelbeck <li...@lo...> >> Date: Friday, 29 September 2023 at 4:43 am >> To: AstLinux Users Mailing List <ast...@li...> >> Subject: Re: [Astlinux-users] Stopping logging of Crontab >> >> Hi Michael, >> >> Looking at the /etc/init.d/crond init script, here [1] >> >> If the line "crond" was changed to "crond -L /var/log/crond.log" it would disable syslog and use that file ... but may need rotating if it gets large. >> >> If the line "crond" was changed to "crond -L /dev/null" it would disable syslog and disable logging (ie. to /dev/null). >> >> BTW, I manually tested both cases to be certain. >> >> Lonnie >> >> [1] https://github.com/astlinux-project/astlinux/blob/09e87eff8bca82bf4afab8dbe09560737dd80d5c/project/astlinux/target_skeleton/etc/init.d/crond#L38 >> >> >> >>> On Sep 27, 2023, at 8:01 PM, Michael Knill <mic...@ip...> wrote: >>> >>> Hi group >>> >>> Replying to this email again. I do understand below but just wondering if there is any way to turn off Cron logging totally or send to a separate log file? >>> >>> Regards >>> Michael Knill >>> >>> >>> From: Lonnie Abelbeck <li...@lo...> >>> Date: Friday, 31 March 2023 at 1:01 am >>> To: AstLinux Users Mailing List <ast...@li...> >>> Subject: Re: [Astlinux-users] Stopping logging of Crontab >>> >>> Hi Michael, >>> >>> The (busybox) crond daemon has a syslog level setting which defaults to 8, the least verbose log level. So no help there. >>> >>> Using the filter for the Status Tab, is a reasonable idea. >>> >>> >>> Personally, when executing shell commands on a regular interval of seconds/minutes, I prefer to use a bash shell script and the sleep builtin. (Using the sleep builtin keeps from spawning a new process whenever 'sleep' is called). >>> >>> The simplest example of this is the 'msmtpqueue' bash script [1] >>> >>> Basic code setup and loop: >>> -- >>> #!/bin/bash >>> >>> LOCKFILE="/var/lock/foobar.lock" >>> >>> # Robust 'bash' method of creating/testing for a lockfile >>> if ! ( set -o noclobber; echo "$$" > "$LOCKFILE" ) 2>/dev/null; then >>> echo "foobar: already running, lockfile \"$LOCKFILE\" exists, process id: $(cat "$LOCKFILE")." >>> return 9 >>> fi >>> >>> # Load 'sleep' builtin if it exists >>> if [ -f /usr/lib/bash/sleep ]; then >>> enable -f /usr/lib/bash/sleep sleep >>> fi >>> >>> #seconds to wait >>> wait=300 >>> >>> trap 'rm -f "$LOCKFILE"; exit $?' INT TERM EXIT >>> >>> while true; do >>> # do stuff >>> >>> sleep $wait >>> done >>> >>> rm -f "$LOCKFILE" >>> trap - INT TERM EXIT >>> -- >>> >>> Look at the actual code [1] for finer details. Another fairly simple example, asterisk-sip-monitor [2] which adds a PID file that can be removed to exit the script. >>> >>> Lonnie >>> >>> [1] https://github.com/astlinux-project/astlinux/blob/master/package/msmtp/msmtpqueue.sh >>> >>> [2] https://github.com/astlinux-project/astlinux/blob/master/package/asterisk/asterisk-sip-monitor >>> >>> >>> >>> >>> >>>> On Mar 29, 2023, at 11:39 PM, Michael Knill <mic...@ip...> wrote: >>>> >>>> Short of putting in a filter for the Status Tab, is there any way to stop Crontab logging to Syslog. >>>> I now have a process that is run every 10 minutes and its annoying that it logs to Syslog each time. >>>> >>>> Regards >>>> >>>> Michael Knill >>>> Managing Director Michael http://www.mksolutions.info |
28 messages has been excluded from this view by a project administrator.
