Flavio's picture

Getting back after 3 years to this site to check DB status, I missed the adminer interface.
 

 - from Firefox: get error: SSL_ERROR_RX_RECORD_TOO_LONG
 - from Chrome: SSL Error

 - from Webmin/Server/Apache/Network I see the port 12322 listening (from ports.conf),
   but no corresponding site configured (availble/enabled)
 - in /etc/apache2/sites no reference to the adminer site (it should be a link to /etc/adminer/apache.conf
 - in /etc/adminer only a lighttpd.conf file pointing to /usr/share/adminer
 - no directory /usr/share/adminer

This issue is only related to adminer: other mgmt interfaces work well.

What happened here?
There's a way to get back adminer reinstalling it?

Thnks a lot
Flavio

Forum: 
Jeremy Davis's picture

TBH, I would be a bit concerned on how that could have happened to your server if I were you. That's not something that should not have just happened all on it's own. And personally, I would be concerned about what other stuff might be missing?!

And v14.x is getting pretty dated now, so probably the best solution would be to migrate your data to a newer TurnKey release (the current is v16.0, v16.1 is on the way and I hope to start work on v17.0 soon).

Regardless, if you just want to get things going again, then you can download the relevant files we provided initially. Although if you don't have a /usr/share/adminer, I have a horrible feeling that the Adminer package may have been removed?! You can check like this:

apt-cache policy adminer | grep -i installed

If the package that v14.2 shipped with, you should get this:

  Installed: 4.2.5-3~bpo8+1

If it's an earlier version of v14.x, then perhaps you might get this:

  Installed: 3.3.3-1+deb8u1

If you get the below, then that means it's been uninstalled for some reason:

  Installed: (none)

Regardless, the actual Adminer files themselves live within /usr/share/adminer, so if that's empty, you need to reinstall it anyway. I suggest installing the slightly newer version like this:

wget wget https://snapshot.debian.org/archive/debian-archive/20190328T105444Z/debian/pool/main/a/adminer/adminer_4.2.5-3~bpo8%2B2_all.deb
dpkg -i adminer_4.2.5-3~bpo8+2_all.deb

To restore the files that we provided:

git clone --depth=1 --branch=14.2 https://github.com/turnkeylinux/common ~/turnkey-common
cp -R ~/turnkey-common/overlays/adminer/etc/adminer/* /etc/adminer
cp -R ~/turnkey-common/overlays/adminer/usr/share/adminer/* /usr/share/adminer

When you're done moving files, then you can delete the rest:

rm -rf ~/turnkey-common

Hopefully that should get you up and running again... :)

Flavio's picture

Hi Jeremy,

thank you so much for you __fast__ help.

I had to find a solution before receiving it, as the website had problems, and webdevelopers didn't like to use mysql CLI...

I merged several thread on the blog, so ended up:

 1. installed http://http.us.debian.org/debian/pool/main/a/adminer/adminer_4.7.9-1_all...
     resolving dependencies (php7.0-pgsql, php7.0-sqlite3, php-mysql, php-sqlite3,  php-pgsql
 

 2. re-created /etc/adminer/apache.conf from
      https://github.com/turnkeylinux/common/blob/master/overlays/adminer/etc/...

 3. made a link in /usr/share/adminer/adminer  to link with apache.conf
     ln -s index.php tkl-index.php

 

I don't know if it is the TKL version of adminer, but the webdevs could work and now the webserver is up and running: what do you think: can I keep it installed, or better remove and re-install following your solution?

Anyway I'm really concerned about 'when' 'how' and 'why' it happened.

I investigated a backup copy and found that:

root@WebSrv01 ~# apt-cache policy adminer | grep -i installed
  Installed: (none)


I went through all apt/dpkg logs since the server setup and didn't find any reference to the adminer package nor to removed packages.

Do you know how to check for other missing things?
I don't thing is a disk corruption: symptoms would have been really different

Yes I'm thinking about migrating to v16, but it would be my first migration, so I'm a it concerned about that....

Pls tell me about you opinion

Best Regards
Flavio

 

 

Jeremy Davis's picture

Glad to hear that you got it up and running again.

Firstly, what you've done sounds a bit messy, but if it works, then IMO it's fine to keep going. At some point you are going to need to migrate/upgrade, so personally, I'd be looking at focusing on that, rather than worrying too much about this server.

Essentially what you've done is installed a newer version of Adminer (from Debian 10/Buster; a much newer version of Debian than 8/Jessie - what v14.x was based on). Generally that sort of thing is frowned on and considered to be a FrankenDebian. However, having a closer look at this specific scenario, with a newer version of PHP, I suspect that it's unlikely to cause any issue; especially consdiering that you installed the deb file directly (rather than adding the newer repo and installing with apt - which would risk pulling in other packages). As you can see the Adminer package only depends on PHP packages so the chances of just Adminer causing any issues is slim.


As to trying to work out what happened, you note that you have installed a newer version of PHP. If you did that prior to installing this newer version of Adminer, then that may have been why? The old Adminer would have depended on PHP 5.6 packages (named php5...), so if you uninstalled any of those, then you probably inadvertently uninstalled Adminer while you were doing that.

You may be able to prove (or disprove) my theory via the apt logs. I suggest trying something like this for starters:

zgrep adminer /var/log/apt/*

Hopefully that will output at least one line (probably multiple lines) in this format:

/var/log/apt/FILENAME.log.XX.gz: MESSAGE_CONTAINING adminer ...

Eg. here's a real line that demonstrates an example line from a search of log file (zgrep acpid /var/log/apt/*) on a server I have handy.

/var/log/apt/term.log.11.gz:Removing acpid (1:2.0.28-1+b1) ...

The first part (before the first ':') is the filename where the match occurs.

If that gives too many results, then you could try searching for the explicit term "Removing adminer":

zgrep "Removing adminer"r /var/log/apt/*

Regardless, if you wish to review the file manually, I suggest use of 'zcat' with 'more'. More is a pager, so you can scroll through the file contents use 'space' to scroll a full page, 'enter' to scroll line by line.

zcat /var/log/apt/term.log.11.gz | more

FWIW you can use 'more' to search for the desired term ('adminer' in my example below - but as per zgrep example above, you can tweak it using more text within the previous search to be more precise). You can do it interactively by typing '\search term' (after running the above command, without the quotes). Or you can add it to the end of the more command as noted below. Note that in 'more', the search term does not need to be quoted but is case sensitive. Some special characters (e.g. '/') may need to be escaped (e.g. '\/'). So as an example, to search for "Removing adminer":

 zcat /var/log/apt/term.log.11.gz | more +/Removing adminer

As to migrating, I suggest that you do a dry run with TKLBAM (i.e. restore a backup to a new v16.x server running as a VM). If you just do that to a test VM, then worst case, it will completely fail and you can trash the VM and start again... You can work through any issues and/or develop a workflow for the migration with no pressure (taking careful notes as you go so you can recreate your steps later when you do it for real). If you hit any hurdles and/or want any suggestions and advice with issues you may hit, please feel free to post.

Flavio's picture

Hi Jeremy,

thank you again for your fantastic support!
You gave to me a lot of good hints, and completely matched my expectations.

What I got:

1. the server can be considered working in good conditions actually

2. a migration to the new TKL version is the next task to carry on: there space to test, try and solve issues w/out any service interruption until last migration step.

3. I think your diagnosis is correct: yes the webdevs asked to have PHP7 installed, so we upgraded the package. Possibly we did in the wrong way, hence the ol'adminer gone; nobody was aware of, as adminer is seldom used.
That means that the server hasn't been harmed and it is trustworthy.

Best regards

Flavio

 

 

 

Add new comment