I wouldn’t bother with hardware now, recreate the 2029 extension, same hardware different number. no zulu involved
1 Like
So from the Asterisk CLI in the GUI I ran
database show CF
I got several entries including th eone I do not want.
I ran
database deltree cf
I got no entries found
running the show CF showed the same entries.
Tried
database del /CF/2029
and got
Usage: database del
Deletes an entry in the Asterisk database for a given
family and key.
That should be
database del CF 2029
I get Database entry does not exist
database show CF ?
It still shows that entry
/CF/2004 : 517499xxxx
/CF/2006 : 517581xxxx
/CF/2009 : 51726xxxxx
/CF/2011 : 51726xxxxx
/CF/2012 : 51741xxxxx
/CF/2016 : 51724xxxxx
/CF/2029 : 2021
hmm . . .
database deltree CF
database put CF 2004 517499xxxx
.
.
.
database show CF
?
1 Like
database deltree CF
No entries found.
database show CF shows all those entries.
I am running these from the GUI Asterisk CLI command line.
stubborn
You might have a corrupt astdb,
rasterisk -x 'database show'|tee /root/astdb.save
do a forensic on /root/astdb.save
a possible ‘ohshit’ resolution if Zulu broke it
fwconsole ma disable zulu (or whatever)
fwconsole stop
mv /var/lib/asterisk/astdb.sqlite3 /root
fwconsole start
expect some problems while astdb is ‘rebuilt’ you might need to one by one re-save each extension
but you should have the rules
How much of this will affect operations of the system? They have about 30 extensions on the system at the moment
I can’t answer that, I personally would do it at 2am on Sunday after taking a good ‘image’
How would (could) you rebuild the astdb? Or is it not possible.
It will rebuild it automatically from the MYSQL entries in FreePBX, what FreePBX can’t do is rebuild the ‘state’ of the devices like DND and call forwarding because that comes from the button presses/history of the devices themselves.
I think I remember that there was a way posted to push as much as possible of the AMPUSER family to astdb after an effup without recommitting every extension, but I suffer from CRS.
I appreciate all your help dicko. I might just tell them they need to delete 2029 and not use it for now and see if anything else comes up. If it does a reimage of the system might be in order. My gut says the system might either have been hacked or has a HD failure coming.
New extensions do not show as connected in the reports and does not get a message that a call is coming. Otherwise they work
It’s a little technical, but due to the way that sqlite3 does record locking (by disk extent) and that asterisk is thread-safe but not multi-user safe while handling the database (hence my suspicion of Zulu) , if you stop asterisk (and thus zulu) , the recommended way for sqlite3 to recover is to use the sqlite3 client to
a) dump the database
b) delete the file from the disk
c) restore the dump
It has worked for me in the past.
What hardware are you doing this on ?
It is a Freepbx distro on I think a I5 system.
This system has been hacked before and the IT guys have not closed the http or ssh ports. So we are thinking it has been hacked again. We might be replacing this system.
ssh should never be on 22 (it’s just unnecessary noise) but never, ever, ever have root access or password authentication enabled (only allow public keys and rotate them regularly). http needs ALWAYS to be written to https with legitimate certs in place.
Scold your IT guys severely 
, rebuilding your system with rkhunter ( or equivalent ) before you do anything else would not be remiss, if you have an i5, memory and drive space, then I would add mondorescue for ‘belt and braces hard metal restore possibility’ cos’ its got the balls.