UrkoM's picture

Hello,

We use Proxmox VE 3.4 in a cluster of 3 nodes. I am trying to deploy Observium.

I downloaded the OpenVZ file, and uploaded it to the Proxmox storage. I deployed the container, and it all seemed to go well.

I used vzctl enter <id> to get into the container, and I was prompted for the passwords: root, Mysql, Observium. It all seemed to go well.

But the services do not autostart. I rebooted the container, and still nothing. At one point, after I changed some networking configuration, I even got the turnkey-init process for a second time after a reboot.

It seems the turnkey-init is not finishing off properly, and doesn't remove or apply some flag to indicate that the container is now configured, the firstboot.d scripts should not run again, and normal services (apache, mysql, ssh) should autostart. After a reboot, netstat -plant shows no open ports.

I've tried with venet and veth interfaces, no difference. Any help is appreciated!

Forum: 
Jeremy Davis's picture

FWIW I just installed the OVZ in PVE 3.4. I did the inithooks via the webconsole and everything works fine!? Reboot and all services up and running... I wonder why it's not working from commandline?
UrkoM's picture

...but we decided to migrate to LibreNMS. So I am just using a standard Ubuntu 14.04 container without TKL now.

How did you get to the web console on the container? As far as I can remember now, containers need something extra added before they can be accessed through the web console. The alternative, what I usually do, is deploy container, then remote console to the host, and "vzctl enter <guest_id>".

Maybe that has to do with it? Maybe I ran the init hooks that way, when other init hooks were being run at the same time on the console? I don't have the machine around to test anymore. But I'll keep this in mind for future container use.

Jeremy Davis's picture

I reckon that it was because you entered via the host. For security TurnKey includes a fence on all headless builds (so the server cannot be accessed (except via SSH) until the initialisation has been completed. If you log in via SSH or use the Proxmox web console then it will auto connect to the screen session running inside the container (where the inithooks are running and waiting for input). As of PVE v3.x the web console should work fine for containers...

Also for future reference you can pre-seed the inithooks if you desire so then you don't need to enter the machine at all. Details can be found in the inithooks docs.

Oh and one other thing; v14.0 templates are complete and ready to use. They are designed for Proxmox v4.0 but have had some basic testing on v3.4 and appear to work fine there too. However they are not downloadable from within the web UI; you'll need to manually download them. Full details are in the announcement blog post.

UrkoM's picture

I'll keep this in mind for next servers I need to deploy. Thanks!

And thanks for the heads-up about 14.0 templates! I am starting to plan for Proxmox v4.0, too, so one way or another, I'll use them.

 

Ovidiu Pacuraru's picture

I have the exact same problem with Proxmox 4.1 + LXC + Observium TKL 14 

 

I have tried connecting with ssh, turnkey-init starts, I set all my passwords and then nothing happens. I cannot access any webinterface as all of them tell me: Please initialize this system... 

 

So I'm caught in a loop, any hints please? Rebooted a few times to no avail.

Jeremy Davis's picture

Thanks for posting Ovidiu! Although TBH I'm so gutted... I only just finished rebuilding the images (due to a bug). And it looks like in the process of fixing that, it seems that something else is broken now...

I haven't worked out why, but it seems that the fence isn't being disabled as it should be once the inithooks are finished. The behaviour is the same as the OP, but I'm 99.9% sure that the cause this time is different.

I'll be back ASAP with a workaround, and I'll probably need to rebuild the images again...

Jeremy Davis's picture

Inside the container (e.g. ssh in):
update-rc.d turnkey-init-fence remove
service turnkey-init-fence stop
FWIW this only seems to affect the container builds so it's not quite as bad as I initially thought... Still a pain though and I will need to at least rebuild the container builds.
Ovidiu Pacuraru's picture

I just ended up in that loop again, executed these 2 commands again and all well again. Any idea why the loop could have triggered again?

Jeremy Davis's picture

We ended up ironing all the bugs and the new images should be all good. Apologies on the pain experienced and hopefully everything is all up and running ok now...
Ovidiu Pacuraru's picture

All good! Thanks a million for fixing things and keeping them up-to-date!

Ovidiu Pacuraru's picture

Thanks for helping out, that seems to have fixed stuff and I can now explore the appliance.

Jeremy Davis's picture

Even though I was annoyed about the news, I really appreciate getting it. Even though it's pain when there are bugs, I'd rather know ASAP and then I can fix it so less users have a bad experience....

I've fixed the issue in the appliances and the affected images are rebuilt and in the process of being uploaded.

Ovidiu Pacuraru's picture

Would you mind adding a few details to the appliance's description as to how it can be updated? The observium page lists different options, just want to make sure I'm not going to break it :-)

Jeremy Davis's picture

I could only find one set of instructions: https://www.observium.org/docs/updating/#community-edition

But yes we will add that to the appliance page. We have started doing that but need to do it for all appliances.

Regardless it shouldn't be an issue straight away as the Community Edition is only released every six months, v14.1 should contain the latest version...

Really when you do anything like that, regardless of how good the instructions are, you should always test first and even then make sure you have a backup!

The beauty of containers is that they can be treated as disposable. So long as you have a current backup, you can launch a new one in minutes. I suggest that when it comes time to update, launch a new container, restore your data and test the update. Then you're testing your backup at the same time! @ birds and all that! :)

Add new comment