| Summary: | asterisk-13.36 - ast_db_put: Couldn't execute statement: attempt to write a readonly database | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Joseph <syscon780> |
| Component: | Current packages | Assignee: | Jaco Kroon <jaco> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | proxy-maint, sam |
| Priority: | Normal | Keywords: | PullRequest |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://github.com/gentoo/gentoo/pull/19912 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Joseph
2020-12-23 22:23:02 UTC
I've tried asterisk-16.13.0 same thing is happening.
When user remove the file: /var/lib/asterisk/astdb.sqlite3
and start astersik this file should be created isn't it?
but /etc/init.d/asterisk start
fail to start and this file isn't created.
This file is created when user type as root: "asterisk" but with wrong ownership.
As a result one can start asterisk with: "/etc/init.d/asterisk start"
but any device that is trying to register to running asterisk is getting error messages:
[Dec 23 16:27:05] WARNING[5481]: db.c:350 ast_db_put: Couldn't execute statement: SQL logic error
-- Registered SIP 'pstn-5665' at 10.0.0.110:5060
> Saved useragent "Audiocodes-Sip-Gateway-/v.5.80A.032.003" for peer pstn-5665
[Dec 23 16:27:05] WARNING[5481]: db.c:350 ast_db_put: Couldn't execute statement: SQL logic error
-- Registered SIP 'pstn-1270' at 10.0.0.110:5060
> Saved useragent "Audiocodes-Sip-Gateway-/v.5.80A.032.003" for peer pstn-1270
[Dec 23 16:27:05] NOTICE[5481]: chan_sip.c:24776 handle_response_peerpoke: Peer 'pstn-5665' is now Reachable. (62ms / 2000ms)
[Dec 23 16:27:05] WARNING[5481]: db.c:350 ast_db_put: Couldn't execute statement: attempt to write a readonly database
-- Registered SIP '369' at 10.0.0.110:5060
> Saved useragent "Audiocodes-Sip-Gateway-/v.5.80A.032.003" for peer 369
[Dec 23 16:27:05] NOTICE[5481]: chan_sip.c:24776 handle_response_peerpoke: Peer 'pstn-1270' is now Reachable. (88ms / 2000ms)
[Dec 23 16:27:05] WARNING[5481]: db.c:350 ast_db_put: Couldn't execute statement: attempt to write a readonly database
-- Registered SIP '55' at 10.0.0.110:5060
> Saved useragent "Audiocodes-Sip-Gateway-/v.5.80A.032.003" for peer 55
[Dec 23 16:27:05] NOTICE[5481]: chan_sip.c:24776 handle_response_peerpoke: Peer '55' is now Reachable. (38ms / 2000ms)
Correcting ownership of "astdb.sqlite3" file does not solve the problem, so I suspect there are other files that have wrong ownership.
I was correct, the problem is with Gentoo initialization/initialization script: /etc/init.d/asterisk start This script suppose to check and/or create the directory permission asterisk:root /var/lib/asterisk but it doesn't. Executing command as root "asterisk", creates that directory and database "astdb.sqlite3" but with wrong ownership "root:root" that is why asterisk can not write to that database The solution is to change ownership of dir from: root:root /var/lib/asterisk to: asterisk:root /var/lib/asterisk and database "astdb.sqlite3" with ownership: -rw-r--r-- 1 asterisk asterisk astdb.sqlite3 Same thing is happening with asterisk-16. Are you folks checking these ebuild before marking them "stable"??? Yes you're right. Sorry, I place the sqlite DB in /var/lib/asterisk/astdb (which is mounted on ramdisk) owned asterisk:asterisk. Other than that single file in /var/lib/asterisk nothing else needs writing for asterisk. Quick fix for you: chown asterisk: /var/lib/asterisk Alternatively, move astdb to a location (/var/spool/asterisk?) which is writeable by asterisk. Long term solutions: 1. Ebuild to set ownership of /var/lib/asterisk to asterisk:asterisk 2. Tamper with default configs such that astdb resides in /var/lib/asterisk/astdb by default, and we install that as asterisk:asterisk 755 by default. I don't like 1 for reasons of security. But do-able. If asterisk owns /var/lib/asterisk it becomes possible that a primary stage attack could result in an attacker updating stuff in /var/lib/asterisk (which includes audio played bck to callers, the static http server content, scripts potentially executed by asterisk or related processes etc ...) - so possibly not excessively serious, but still preferred to be avoided. /var/spool/asterisk on the other hand I don't like 2 for reasons of migration complexity (existing installed systems). Basically we'd need to install the additional folder. And at asterisk startup, determine if /var/lib/asterisk/astdb.sqlite3 exists, what the configured astdb dir is and then move it to the configured folder (or we can make assumptions, or simply fail startup or something). Either way, this gets really nasty very quickly. Or force the user to manually migrate first if this is an existing install in pkg_setup() ? I do like option 2 better for "new installs", but tricky to migrate existing installs. Ideas or comments? Thank you for looking into it. I hope it will solve other some frustration. It must be a bug from the asterisk upstreem branch as I've notice a lot of similar messages on other forums.
Another problem I have with asterik-13 and asterik-16 is the MWI.
asterisk-13 takes over an hour to clear the MWI light
In astersik-11 MWI light was cleared as soon as I checked the message.
In asterink-13 it takes about 20min to set the light ON and the light
takes over an hour to clear. (I've standard POTS phones)
What had changed?
In sip.cong
[400]
...
mailbox=400
voicemail.conf
[default]
400 => ,user, email
I've tried to enable in sip.conf "subscribemwi=yes" but it doesn't help.
On Asterisk-mailing-list someone commented that they had experience the same thing after upgrading to Asterisk-13 and the problem was solved by upgrading to asterisk-16
--------quote-------
I had this problem following an upgrade between releases of Asterisk 13 last year, but I upgraded to Asterisk 16 and the problem went away without any need for configuration changes.
Julian
------end quote-------
I just emerged astersik-16.13.0 but it didn't solve the problem. The MWI light on my phone does not light up.
I know they change the way MWI works starting from asterisk-12 but. I can not find any instruction how to make it to work.
Any pointers?
....{@} * {@} * {@} Merry X-mas and a Happy New Year!
{@} * {@} * {@} * {@} Wish you all extra ordinary good luck!
{@} * {@} * {@}
\ \ \ 2021 / / /
Hi, (In reply to Joseph from comment #4) > Thank you for looking into it. I hope it will solve other some frustration. > It must be a bug from the asterisk upstreem branch as I've notice a lot of > similar messages on other forums. Interesting. And I think you may be right (from 16.15.1-r1 ebuild): 265 diropts -m 0750 -o asterisk -g root 266 keepdir /var/lib/asterisk Our init script in 11 used to perform some resets, wonder if that's not perhaps the change you're after. I suggest we keep root:root for /var/lib/asterisk - but then store asbdb elsewhere not in there (I just need to figure out migration). Even if the process ends up blocking in pkg_setup() and forcing manual migration. > Another problem I have with asterik-13 and asterik-16 is the MWI. > > asterisk-13 takes over an hour to clear the MWI light > > In astersik-11 MWI light was cleared as soon as I checked the message. > In asterink-13 it takes about 20min to set the light ON and the light > takes over an hour to clear. (I've standard POTS phones) > > What had changed? Both chan_sip? File a bug upstream please. I'm probably one of the only people still willing to touch chan_sip. Once logged upstream, you're welcome to prod me. If I recall I saw similar things off late, but haven't bothered investigating just yet. Should be a separate bug here too, but let's please first fix that upstream, not @ Gentoo. > I've tried to enable in sip.conf "subscribemwi=yes" but it doesn't help. > On Asterisk-mailing-list someone commented that they had experience the same > thing after upgrading to Asterisk-13 and the problem was solved by upgrading > to asterisk-16 If that's the case, we're too late, 13 is in security-only mode now. I'm going to be pushing for 16 stable early in 2021 (hopeful by March). Adding 18 builds as ~, and keeping 13 in case someone really needs it. Will probably hard-mask around middle of the year and give 3-6 months heads up. Kind Regards, Jaco I would like to submit a bug report but I don't know where to. Can you provide a link? I'm not a developer just an end user. (In reply to Joseph from comment #6) > I would like to submit a bug report but I don't know where to. > Can you provide a link? > > I'm not a developer just an end user. https://issues.asterisk.org/ Please just confirm affected versions first. I created an upstream bug: https://issues.asterisk.org/jira/browse/ASTERISK-29224?filter=-2 Maybe somebody will look into it. As I've mentioned because of MWI light not working, I can use use ver.13 in production. This bug had not been fixed in Ver.13 which is obsolete; they no longer accept bugs issues for this version. This bug had been carry over to ver. 16 (I'm currently on 16.13.0); which is not suitable for production because of this bug. They are introducing new versions without fixing old one. What is the point of moving forward when old stuff doesn't work? Starting with Asterisk-18 channel-SIP will be obsolete, replaced by "pjsip". Introducing new can of worm. Will our equipment work with pjsip is a big question mark. In production, we need reliable technology. My asterisk-11.25 is still working in production as all seem to work. Hi All, Just want to update. Whilst I pushed a -r2 (still WIP), this is specifically not included since it's a fairly major change. I'm assuming that existing systems will keep working, but new systems are a problem (and there is a simple workaround). Fixing this for new installs should be fairly easy, but I'm trying to figure out how to handle existing installs. It shouldn't be difficult for an existing installations. Write some kind of a script to check for correct ownership of the file and directory asterisk:root /var/lib/asterisk and database "astdb.sqlite3" with ownership: -rw-r--r-- 1 asterisk asterisk astdb.sqlite3 If it is anything else, overwrite it. Hi, (In reply to Joseph from comment #10) > It shouldn't be difficult for an existing installations. Write some kind of > a script to check for correct ownership of the file and directory > > asterisk:root /var/lib/asterisk existing ownership permissions aren't modified. However, the above really is the *wrong* ownership, root:root is more appropriate. The *only* reason asterisk needs write here is because of astdb ... which is why I'd prefer to put it in a folder of it's own under /var/lib/asterisk, namely /var/lib/asterisk/astdb - and update the defaults to point there too, but existing astdb files will need to be migrated. Something in the init script might be good enough to detect that /var/lib/aterisk/astdb exists, as well as /var/lib/asterisk/asterisk.sqlite3 and rather warn the user and refuse to start. coredump is already like this, so /var/lib/asterisk/coredump is asterisk:asterisk since in the case of a coredump the kernel will (if asterisk init script set it up) write, as the asterisk user, a coredump file here. If you look at everything else in /var/lib/asterisk, it's root:root and that's adequate (and in my opinion, better - there is no reason for asterisk to be able to write to ANY of that). I can check the current settings, but you need to keep things like binary packages in mind too. The one sticky issue is that I can only access the filesystem during certain phases due to more and more strict sandboxing (which is a good thing). > and database "astdb.sqlite3" with ownership: > -rw-r--r-- 1 asterisk asterisk astdb.sqlite3 This is right, but in and by itself not good enough due to: -rw-r--r-- 1 asterisk asterisk 13K Jan 9 12:54 astdb.sqlite3-journal Which only exists as long as sqlite has the database open. Joseph, I realize it's not 16/18 yet, but would it be possible for you to test this ebuild so long as well? https://github.com/gentoo/gentoo/blob/55aab032d45d698f08ef8e81212f4e2b45c1827b/net-misc/asterisk/asterisk-13.38.2-r1.ebuild I'll be applying the same changes to the 16 ebuild and then hopefully sort out an 18 ebuild too asap. Kind Regards, Jaco The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c21e28747944f84b98359b37cfe4d2f2e0b7bb0b commit c21e28747944f84b98359b37cfe4d2f2e0b7bb0b Author: Jaco Kroon <jaco@uls.co.za> AuthorDate: 2021-03-13 19:59:24 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2021-03-19 08:51:49 +0000 net-misc/asterisk: rev bump for 16. Same changes as for 13, except that format_ogg_speex isn't being dropped since it it was introduced in 16. Closes: https://bugs.gentoo.org/772821 Introduce USE=deprecated to enable deprecated apps/funcs/features. For now, this is only app_macro. Closes: https://bugs.gentoo.org/775005 net-misc/asterisk: injects some CFLAGS. Thanks Sam. Closes: https://bugs.gentoo.org/767262 systemd automagic dependency. Closes: https://bugs.gentoo.org/775353 Make asterisk depend on the pjproject SUBSLOT. Ie, rebuild if pjproject gets updated. Closes: https://bugs.gentoo.org/761442 Repair "security" issue in that /var/lib/asterisk can now be root:root. The problem with having it asterisk: is that any arbitrary code vuln becomes a data modification one. So with this as root:root we can at least prevent modifications to /var/lib/asterisk whilst still allowing /var/lib/asterisk/astdb to be modified as required. Repair default voicemail selection. Thank you pkgcheck scan. Drop ASTCFLAGS= and ASTLDFLAGS since ./configure already imports these. I believe Tony added this as a hammer to deal with 775005 above since these got re-added again after the asterisk injected ones. By setting DEBUG= and OPTIMIZE= this problem should now be something of the past. Introduce GENTOO_ASTERISK_CUSTOM_MENUSELECT= environment variable that can be set from make.conf and takes a string similar to USE flags, except that these gets passed to menuselect one by one, if -option as --disable option, else --enable option. Prefixes + and - is supported, and will be stripped before passing to menuselect. menuselect has been patched to exit non-zero in case of invalid option passed to --enable or --disable, resulting in above being reliable (if you have something invalid in there, it will die). Accordingly drop format_ogg_speex which doesn't exist in asterisk 13. Drop no longer required ncurses dependencies (system libedit). Explicitly pass ASTCACHEDIR=/var/cache/asterisk, and update install patch to not install this path, handle in tmpfiles and initd since we're not supposed to install into /var/cache either ... Package-Manager: Portage-3.0.13, Repoman-3.0.2 Signed-off-by: Jaco Kroon <jaco@uls.co.za> Signed-off-by: Joonas Niilola <juippis@gentoo.org> net-misc/asterisk/asterisk-16.16.2-r1.ebuild | 365 +++++++++++++++++++++ .../asterisk-16.16.2-no-var-run-install.patch | 2 +- net-misc/asterisk/files/asterisk.tmpfiles3.conf | 2 + net-misc/asterisk/files/confd-16.16.2-r1 | 171 ++++++++++ net-misc/asterisk/files/initd-16.16.2-r1 | 363 ++++++++++++++++++++ net-misc/asterisk/metadata.xml | 3 +- 6 files changed, 904 insertions(+), 2 deletions(-) Additionally, it has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2c7d0aa6515bffacdaed2237cd28231100465422 commit 2c7d0aa6515bffacdaed2237cd28231100465422 Author: Jaco Kroon <jaco@uls.co.za> AuthorDate: 2021-03-13 12:13:02 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2021-03-19 08:51:49 +0000 net-misc/asterisk: version bump for 13. This is primarily aimed to fixing bugs, asterisk 13 is sec-only upstream, so no further fixes will be made except to address bugs reported to bus.gentoo.org. Note that bugs aren't being closed since 16* is still affected (will be fixed on next bump, just waiting for 16.17.0 to be cut). Bug: https://bugs.gentoo.org/775005 net-misc/asterisk: injects some CFLAGS. Thanks Sam. Bug: https://bugs.gentoo.org/767262 systemd automagic dependency. Bug: https://bugs.gentoo.org/775353 Make asterisk depend on the pjproject SUBSLOT. Ie, rebuild if pjproject gets updated. Bug: https://bugs.gentoo.org/761442 Repair "security" issue in that /var/lib/asterisk can now be root:root. The problem with having it asterisk: is that any arbitrary code vuln becomes a data modification one. So with this as root:root we can at least prevent modifications to /var/lib/asterisk whilst still allowing /var/lib/asterisk/astdb to be modified as required. Repair default voicemail selection. Thank you pkgcheck scan. Drop ASTCFLAGS= and ASTLDFLAGS since ./configure already imports these. I believe Tony added this as a hammer to deal with 775005 above since these got re-added again after the asterisk injected ones. By setting DEBUG= and OPTIMIZE= this problem should now be something of the past. Introduce GENTOO_ASTERISK_CUSTOM_MENUSELECT= environment variable that can be set from make.conf and takes a string similar to USE flags, except that these gets passed to menuselect one by one, if -option as --disable option, else --enable option. Prefixes + and - is supported, and will be stripped before passing to menuselect. menuselect has been patched to exit non-zero in case of invalid option passed to --enable or --disable, resulting in above being reliable (if you have something invalid in there, it will die). Accordingly drop format_ogg_speex which doesn't exist in asterisk 13. Drop no longer required ncurses dependencies (system libedit). Signed-off-by: Jaco Kroon <jaco@uls.co.za> Signed-off-by: Joonas Niilola <juippis@gentoo.org> net-misc/asterisk/asterisk-13.38.2-r1.ebuild | 348 +++++++++++++++++++++ .../asterisk-13.38.2-r1-menuselect-exitcodes.patch | 67 ++++ 2 files changed, 415 insertions(+) |
