bhruska's picture

I've got four servers/sites running the wordpress appliance: 

TurnKey GNU/Linux 14.2 / Debian 8.11 Jessie

I was just preparing to rebuild them with the 15.3 version, with the idea that I'd get the latest PHP release, but I see it is not PHP 7.3, which wordpress is reporting as the "minimum" version.

I see some comments that there's a new "core" in the works, so perhaps I should wait to rebuild these systems.

Is there a timeframe on that upgrade?  

Thanks,

Brian

 

 

 

Forum: 
Jeremy Davis's picture

You heard correctly. Although it's running way behind schedule... I had hoped to have it released way before now...

Anyway, the v16.0 RC (release candidate) of Core should be available REALLY soon (sorry I can't decode that into specific number of days - but ASAP). Once that is available, then hopefully we'll get some user's testing it and reporting how it goes. With some confirmation that all is well, we hope to start providing other appliances from the library. We will be looking to produce them in batches.

LAMP will almost certainly be in the first batch, and quite possibly WordPress too.

And v16.x will include PHP 7.3. Although it's probably worth noting, that whilst v15.x includes PHP 7.0 (which is no longer maintained by PHP themselves), we install PHP from Debian and they will be providing backported security patches for PHP 7.0 for some time yet (at least until mid 2022 - if not longer).

So if you feel in need to urgently update, then moving to v15.x should still provide benefit over earlier releases. But if you can afford to wait a little, then v16.0 should be a superior option.

I hope that helps...

bhruska's picture

Jeremy,

I'm told by my web people we are no longer able to update Wordpress plugins for a number of our sites because it does not have PHP 7.3.  We had a site completely crash when an update was accidently made.

Any update on your timeframe here?

I'm getting lots of static on this.

Thanks,
Brian

 

 

Thanks,

Brian

Jeremy Davis's picture

Apologies that things aren't moving as fast as any of us would like. I'd like to give you a little insight into what still lays in front of us here at TurnKey and some more thoughts on PHP, WordPress and plugin compatibility. I'll also note your options as I see them in the final section below. I wanted to provide the full depth of my understanding, as much for others who may be in your situation as for you. Please feel free to skip straight to that last section if you're in a rush...

Where we're at

Things haven't gone as fast as I would have liked. We're still probably at least a week or 2 out from a v16.0 WordPress appliance (possibly a little more if things don't go as smoothly as I anticipate). Things are definitely moving in the right direction though. Just yesterday I published a blog post announcing the release of Core v16.0rc1.

FYI, our next steps will be to ensure that all the other build targets (besides ISO) are building and working ok. Hopefully, things don't require too many significant changes and it all goes smoothly and quickly. During the time I'm working on that, hopefully lots of TurnKey users battle test Core (and TKLDev, and even assist with getting other appliances ready for publishing) to ensure that the basis of our new release is all good.

Once I have all the additional builds working, and have resolved any issues that may have cropped up from testing of the RC, then we'll move to publishing appliances. The plan will be to publish them in batches of around 10 (or more) at a time, as they're ready. As you might expect, Core and TKLDev will be in that first batch. I also intend to include LAMP and a number of our most popular LAMP based appliances, including WordPress in that first batch.

Round up of your current situation

So from what I understand, you are currently using a TurnKey v14.x appliance. That only provides PHP v5.6.40. Considering 5.6 has been EOL (end of life) upstream (i.e. the PHP developers) for over a year now, plus significant performance gains were introduced with PHP 7.0, I completely understand many WordPress plugin developers dropping support for that. Although it's perhaps worth noting that despite WordPress recommending PHP 7.3, the WordPress "requirements" page explicitly notes that the minimum requirement is PHP 5.6.20 (or higher). So if there is incompatibility with PHP 5.6, it's the plugins that you are using, not WordPress itself.

We haven't explicitly noted it in our previous discussions, but TurnKey v15.x provides PHP 7.0.33. Out of interest, I just did a quick random survey of a few popular WordPress plugins, and all the ones I checked support PHP 5.6+ (so implicitly also support 7.0). Although it was hardly scientific and as I noted above, I can understand plugin devs dropping support for older PHP. I'm sure that some smaller, less popular and less well resourced plugin providers have made the commercial decision to drop support for older EOL PHP versions (PHP upstream only support PHP v7.2+ currently). As something of an aside (and perhaps irrelevant to you), Debian 9/Stretch (the basis of TurnKey v15.x) will continue to provide backported security patches for PHP 7.0 (automatically installed by TurnKey's auto sec updates) until at least June 2022 and most likely well beyond.

So as I noted in my initial post in this thread, whilst v16.0 will be optimal, v15.x would still be of benefit. And depending on the specific plugins that you are using, might even be enough to meet your immediate needs (obviously this will depend on the individual plugins you are using). I guess if you are using plugins developed inhouse though, then that may be a different matter?!

Some more thoughts on compatibility

Personally, I'd be asking your web people for a comprehensive list of what minimum version of PHP each plugin actually needs. If I were you, I'd also be asking for confirmed max WordPress version compatibility of each plugin too. FWIW I noticed in my above (random and unscientific) check of popular WordPress plugins, that a couple weren't actually confirmed as working with the latest version of WordPress (they may still work ok, or perhaps not). So there's a (possibly slim, if your web people are onto it) chance that may also be a factor in your woes?

Bottom line is that it may well be the case that one or 2 (or perhaps more?) might actually require PHP 7.3. But it's quite possible that may only be a recommendation and 7.0 may be enough to meet minimum requirements (in which case moving to v15.x for now may be sufficient).

If you definitely need PHP 7.3 - Now!

If you definitely need PHP 7.3 right now and can't wait, then you could upgrade to v15.x and install PHP 7.3 - as per Jose's forum tutorial. The guy that provides the 3rd party deb.sury.org PHP repo (Ondřej Surý) is one of the Debian (and Ubuntu) PHP package maintainers, so he knows his stuff and is trustworthy. The downside though, is that you'll no longer get automated security updates for PHP. Also, he doesn't guarantee support for a particular PHP version beyond upstream EOL (as Debian does) - although it sounds like that's unlikely to be a concern for you.

Another option would be to upgrade to v15.x and then do a Debian "in place" upgrade from the Debian 9/Stretch base to a Debian 10/Buster base (what v16.x will be based on). I can't 100% guarantee that will work smoothly and everything will be ok (although TBH, I would expect that it would). You could even do that from your current install, although you can't skip a release (i.e. you'd need to go 8/Jessie to 9/Stretch, then to 10/Buster).

Note that if you do take the "in place" upgrade path, you will have something of a hybrid. All the packages will be updated, but some tweaks made by us will be overwritten by changes as you upgrade. Other additional tweaks that we provide (at build time) you won't get. So whilst it will be close to v16.x, a system upgraded like that won't be exactly the same as a v16.x server.

Sorry that it was a bit long... Regardless, I hope that it helps.

bhruska's picture

I appreciate you laying out various other options.  By the time I would successfully upgrade all five of my machines with the "interim" fix, you'll probably be done with your work.  I certainly don't want to go through the upgrade hassles more than once, if I can avoid it. 

I'd also like to be on your standard VM, because of all that you guys do so well!  Upgrades, patches, etc.

So I think I'll just im-patiently wait....  I would think Wordpress is one of your more popular VMs, so my issues can't be mine alone.  Good luck, and keep us informed.

Thanks for all you do,

Brian

 

Thanks,

Brian

bhruska's picture

Any update on this project?

Thanks,

Brian

 

Thanks,

Brian

Jeremy Davis's picture

Yeah it's so close I can almost taste it... Just a last few little pieces I need to get in place and I'll start publishing stable appliances. I hate to make promises when I don't control all the variables, but I'm really hoping to be start releasing this week...

FWIW I'm just finalising the webserver security config...

bhruska's picture

Must be close now.  Any updates?

Thanks,
Brian

Thanks,

Brian

Jeremy Davis's picture

Apologies on the hold up. I kept finding bugs... Although I'm pretty sure that I've got there now (have finished testing Core with a fine tooth comb, plus a few LAMP based apps too).

I'm literally building the first batch of 10 ISOs now (which the other builds are built from). Assuming that there are no (further) obvious bugs, they will be "ticked off" by this afternoon my time. So fingers crossed, published early next week.

Jeremy Davis's picture

As per my response to Brian a minute ago, the first batch should be ready early next week. I didn't explicitly note it in that post, but WordPress will be in that first batch.

A 3+ yo instance is really old! I assume that is probably a v14.2 instance (with PHP 5.6)?! The new upcoming one will be v16.0. Given that is a jump from 2 major versions ago, I'm not 100% sure how an automated data migration will go. But I'm open to give you a hand (here via the forums for free; or one-on-one if you're open to paying) to migrate your data with TKLBAM if you are interested. I can run some tests, but to actually be able to be involved with a "real world" migration would be quite interesting and could give me some further insight to assist with this.

bhruska's picture

I won't be able to migrate it.  I'll just spin it up, make my tweaks, then restore the wordpress files.  Obviouly I'll test and let you know if anything shows up.  Thanks for the good work.

Brian

 

Thanks,

Brian

Jeremy Davis's picture

Assuming nothing (else) goes wrong, then LAMP (and WordPress, OTRS and a few others) should definitely be published this week.

LEMP, I'm not 100% sure on just yet. No one has looked at that one, but once we get the first batch done, we should be able to get most of the others out pretty quick. As you've explicitly noted/requested it, I'll try to ensure that it gets some priority (and it should be pretty easy anyway). Regardless, hopefully it shouldn't be too far away.

Jeremy Davis's picture

I just wanted to let you patient people where things are up to.

I have built and tested the first batch of 10 appliances. The appliances in this first batch (in alphabetical order) are:

  • core
  • django
  • gitea
  • joomla3
  • lamp
  • lapp
  • nextcloud
  • otrs
  • tkldev
  • wordpress

Currently we're awaiting the final step of the process which is review by my colleague Alon. Assuming he's happy, he'll then sign and publish them! I was really hoping that he'd be able to do that this week, but at this stage it's looking unlikely that he'll get that finalised before the weekend. :( In the unlikely even that he's not happy, then it may delay the final publishing by a day (although history suggests that usually it'll just be some minor niggles which we'll open issues for and patch in the next release of that appliance).

In an effort to get them published ASAP, I have only built to ISO and AMI (for the Hub) at this point. I almost have the VM (OVA & VMDK) builds working, but I still need to do some more testing. LXC/Proxmox builds will most likely follow after them.

There is a possibility that I might get the VM builds done before Alon does his review and if so, they'll be published at the same time as the ISOs & AMIs. Similar (but less likely) for LXC/Proxmox builds.

bhruska's picture

Great news.  I've been looking every day.  Will you email us when they are finally available for download?

Is zurmo going to get an update?  I have been using it for years, and the appliance is quite old.

Thanks again,

Brian

 

Thanks,

Brian

Jeremy Davis's picture

I'll aim to post here when they're actually published, so if you get email notifications of posts to this thread you'll get a notification. And/or I intend to send out a "newsletter" email noting the first stable appliance release which you should get if you are subscribed to the TurnKey "newsletter" (if you're unsure, please log in, go to your user profile and check your current subscriptions.

Re Zurmo, yes we'll definately be updating it, but I'm not sure when. Although now that you've noted it, I'll try to get it into the next batch.

Jeremy Davis's picture

The first few v16.0 appliances are done. The first batch includes WordPress and Nextcloud, plus a few others. Please have a look at the blog post for more info.

Apologies that it took so long and thank you all so much for your patience.

We hope to keep publishing batches of v16.0 apps at least weekly until they're all done.

bhruska's picture

When are the other formats for Wordpress going to go up?

Thanks,
Brian

 

Thanks,

Brian

Jeremy Davis's picture

Which format are you after Brian?

Regardless, at this stage we will probably look to build a number of other formats at least for Core and wait for feedback before we proceed. That's be because we don't have direct access to the different platforms to test. If you have access to one of those platforms, perhaps you could assist with testing?

FWIW I did start pushing Docker builds to the Docker Hub, but then noticed some weirdness, so I hope to have a closer look at those and may redo what I have pushed already.

Although until we have the whole library done, the main focus will continue to be pushing out the updated appliances in ISO, LXC and for the Hub. I plan to publish at least 10 apps per week.

bhruska's picture

I'm ready to start building a new VM, and I don't see the OVA format, which is what I've always used.  I guess I can use the ISO. I will try using that.   

Are you expecting updates soon?  Am I good to use this baby?  

Thanks,

Brian

 

Also wondering about Zurmo.  ;)

Thanks,

Brian

Jeremy Davis's picture

I already noted where things are with the OVA build below, but to answer your questions re Zurmo:

TBH, I'm not really sure what is going on with Zurmo?! According to this post (posted Dec 2016) as of v3.2.0, Zurmo is compatible with PHP7.x (current Zurmo stable version is v3.2.7). However, when we updated the appliance for v16.0, we're getting a ton of PHP errors. Digging in a bit more, it seems that whilst it may be compatible with PHP 7.0 (or perhaps even 7.1) it's not compatible with 7.2/7.3. See relatively recent (i.e. within the last year) comments on the installation wiki page.

Doing a bit more digging, it seems that Zurmo may now be essentially "abandonware" (i.e. software that has been abandoned)!? The most recent note on their roadmap suggests that v3.3 should be available "Fall/Winter 2016" (and as I noted above, the current version is v3.2.7 and I couldn't find any sign of a v3.3 version in the source code). As of some time ago, the only active developer appears to be a guy named Boban Perić. Interestingly, he's not listed on the about page. And even then, he was last active on the Zurmo forums ~11 months ago. The source code appears to have been migrated to an alternate BitBucket account and the last commit was Sept 2019.

So as I say, it appears that it may be "abandonware". It's a real pity as it's pretty cool and quite unique software. If we had a PHP developer on the team and had spare cycles, I'd almost be tempted to at least patch it for the purposes of providing a v16.0 build of the appliance, but we don't. so I don't see it happening... :(

Bottom line, unless there is a Zurmo revival, or at least a fork that has been patched to work with PHP7.3, at this point, I don't see there being a v16.0 Zurmo appliance.

bhruska's picture

I'm trying to install this baby in VMWARE 6.5, and getting lots of crashes.  

The networking dialog crashes trying to set a static IP address.  I've attached a screen shot.

Also, any progress with the OVA?  Its not obvious to me which defaults to use with the ISO.  The OVA was always so simple... I couldn't screw it up!  It just worked.

Thanks,
Brian
 

Thanks,

Brian

Jeremy Davis's picture

I'll have to have a look at Confconsole code re that error ASAP. I'm sure that I've personally tested setting a static IP and don't recall hitting that?! Hopefully I can recreate it, if not, I might have some more questions for you. Regardless, I'll have a look and get back to you ASAP.

When you say "VMware 6.5", are you're referring to "VMware vSphere/ESXi 6.5"? If so, could you please share the explicit release/build number? If you're not sure how, this VMWare doc seems to cover it. If you'd rather not share that detail publicly, then please feel free to email that to me (jeremy AT turnkeylinux.org).

Re the ISO install, generally, you should be able to just accept all the defaults. Although now you mention it, I do recall that my VMware tests had issues automatically determining where to install grub to. I'll revisit that and at least document it.

Re OVA, we have just published Core v16.0 as OVA (I haven't announced it yet). I don't have access to vSphere/ESXi so I'm hoping that we can get a bit of community testing before I start rolling it out. Would you mind giving that a quick test drive and see if it works for you?

Jeremy Davis's picture

I haven't been able to reproduce this issue?! I've also tested in a VMware Player (v15.5) VM too, just in case it's something that only shows up in VMware, but I couldn't get it to occur there either?! Unfortunately, I don't have ESXi/vSphere or Windows, so reproducing your environment is not currently possible.

While trying to reproduce this issue, I tried every combination of characters that I could imagine but beyond finding another (different) bug in Confconsole (some python2 code we missed when porting to python3), I haven't been able to reproduce this issue. Beyond that particular bug (caused by a valid IP address from a different subnet to the gateway IP), all other things that I tried produced an "Invalid IP" error, rather than a crash and a stacktrace as yours did. I guess that's something (finding a bug we'd previously missed) but it's not really helping me resolve this specific issue you're hitting... :(

Do you recall anything in particular that you did when that error occurred? If you still have the WordPress appliance running, could you please try again? This time note exactly what buttons you press.

The only thing that I can think of is perhaps the VMware interface passes through the exact Windows key codes to Confconsole and that upsets it? FWIW in Linux, the "Enter" key returns a single "newline" or "linefeed" character (aka 'LF' - aka ASCII character code 10 - aka '\n'); whereas "Enter" on Windows returns 2 characters, a "newline", but also a "carriage return" character (aka 'CR' - aka ASCII char code 13 - aka '\r' - i.e. together; 'CRLF' or '\n\r'). In other words, Linux assumes that a new line always starts at the far left, whereas Windows doesn't. TBH I'm not convinced that is the cause as I would have expected it to have caused an issue sooner, rather than just in this particular place. But I can't think of any other reason why it would happen?!

One way that you could test if that's the issue if you want is when trying to change the IP to static, instead of using the "Enter" key to select "Ok", instead hit the "Space" key. You will probably need to use the "Tab" key to move the cursor from the IP text input box, to the "<Ok>" button, then hit "Space" to select the highlighted option.

Regardless, I'll get my colleague (who is much more of a Python expert than me) to look into it first thing Monday. Hopefully he'll be able to see what the issue might be. If you have anything to add before then (e.g. try with the space key instead as noted above), I'd love to hear.

PS - I've opened an issue for this.

Jeremy Davis's picture

Ok, so we're fairly sure we've worked out the direct cause for the Confconsole crash (and the stacktrace). So we'll make Confconsole a bit more robust and provide a more useful error message, rather than just crash.

However, we're still not sure why the scenario that caused Confconsole to crash in the first place occurred (i.e. even once we improve Confconsole, the underlying cause will still exist). I have a suspicion what might have caused it, but I'm going to do some testing before I say too much more.

You can see more details/discussion on the issue.

bhruska's picture

Jeremy,

The vSphere version is 6.0.0, 5050593

The defaults with Grub gave me an issue.  I had to retry this a couple times and finally got it right.  

I tested the static IP issue twice to make certain I didn't do anything wrong.  Its definately a dialog box error of some sort.

It was also a bit weird it asked me for the "wordpress" login user and password in the console in text mode after it had already asked me to enter the passwords via the dialog boxes.  That was very confusing, as I've never seen that.  It turns out it was the prompt of the computer, which is named "wordpress", not the one for wordpress itself.  So it wanted the root user, and computer password I had supplied.  It took me a few tries to get that right because the user code to use was not obvious. 

I will test the core, hopefully Thursday afternoon Chicago time.

Thanks,
Brian

Thanks,

Brian

Jeremy Davis's picture

Thanks heaps for the extra info Brian.

I just posted re Zurmo above (sorry I missed that post earlier).

Thanks for your further info re your experience with the ISO on VMware. It only seems to occur on VMware, so I'm not really sure why that is?! I'll definitely double check that some more and at the very least open an issue and note how to make it work, so then at least it'll be documented.

Re your note about it asking again for the '"wordpress" login user and password in the console', I assume that it was terminal log in prompt? (I.e. log in for the server with a hostname of "wordpress" as the 'root' user and the root password you set on firstboot)?! I probably didn't elaborate enough on the inithooks/confconsole changes in the release blog post, but I did note it in a comment if you're interested?

I still haven't had a change to look into the Confconsole static IP stuff yet, but I'll get to that shortly.

bhruska's picture

I got this message attempting to load the Core 64 bit OVA.  This was on the vSphere windows client.  It looks like its having an issue with the version of Debian perhaps.  Not sure.

The web client gives me a different error message that I can't seem to get around.  This may be related to my location in some way, I'm not sure.  Still trying on that one.

Thanks
Brian

Thanks,

Brian

Jeremy Davis's picture

Bugger.

FWIW, historically we've used 'id 102' which is "Other (64-bit)". Experience shows that is generally backwards compatible with older VMware products. I knew that accepting the default value that the current (v4.4.0) VMware OVFTool sets ('id 96' which incidentally is "Debian (64-bit)") would break compatibility with ESXi v5.5 (and earlier). But my research suggested it should be ok with v6.0 onwards. I only have access to current VMware stuff, so can't test backwards compatibility. I was looking forward to it being correctly identified, but looks like not yet... It seems like I must have misinterpreted something or what I read was wrong.

Anyway, I'll revert back the tweak that sets it to 'id 102' and rebuild. Hopefully that should do it. I'll let you know once we're good to try again, I anticipate early next week. Thanks again for testing.

PS Hopefully I'll get to that Confconsole static IP issue today too...

bhruska's picture

Any progress on the Wordpress with the fixes?

Thanks,
Brian

 

Thanks,

Brian

Jeremy Davis's picture

Hi Brian,

Could you please double check the updated Core OVA and confirm if it now works for you? I'm feeling pretty confident that it will, but the previous one passed all my tests too though, so fingers crossed...

If you hit any more issues, please report back ASAP with as much info as possible. If I can get a confirmed working Core OVA by COB Friday, then I should be able to have a WordPress OVA for you early next week.


The rest of this post relates to the networking issue you hit when you installed the ISO. We have done some investigations and discovered the underlying issue. Unfortunately it runs much deeper than I might have liked. On the upside, it actually seems to be fairly rare (unfortunately VMware does seem to be particular fragile - not sure why). I still need to do a little more testing before we decide on the exact path forward.

Without more specific info on the networking config you used, we're still not 100% sure exactly what went wrong in your case. But our testing to date reveals that in Debian Buster (the base of v16.x) the minimalist Debian DHCP client we're using (udhcpc) does have some race condition with the network config. Under some circumstance, it fails to configure network routing information. Confconsole should handle that scenario ok (although networking wouldn't work), but it was failing when trying to set a static IP if the routing info was missing.

So whilst we've improved Confconsole's handling of the underlying issue(s), including error reporting; we haven't found a satisfactory way to resolve the underlying race condition (when it occurs). Luckily it seems pretty uncommon, although as I said, unfortunately, VMware does seem to be a particularly fragile platform. I'm fairly certain that it may also occur on other platforms, but without manually removing the routing info, I've been unable to reproduce it on other VM platforms such as KVM or VirtualBox. We did put some time into trying to see if we could automate retrying to get routing info on failure, but that became a bit of a rabbit hole. So we've backed out until we can get more info about the specific circumstance when users hit that. Another pathway may be to test an alternate DHCP client.

bhruska's picture

Good news is there was no error loading the OVA in VMWare.  It loaded clean, and then powered on okay.

But, there was still the strange login request asking for the root login and password in TEXT mode.  Screen attached.  That seemed to work okay, but again I don't recall it ever doing that before.

Then, there is still the dialog box errors when I select the static IP address option.  Since I don't have a DHCP server, I'm stuck here.  In fact, I have to force power off because there's no way out of the dialog boxes.  Obviously this is a deal killer.

Let me know if you have something else you want me to test.

Thanks,
Brian

Thanks,

Brian

Jeremy Davis's picture

Before I start, I'd just like to really thank you for your assistance with testing and troubleshooting; as well as your legendary patience while we work though the issues. Your contribution here is invaluable! And I really hope to repay it with getting you your working WordPress OVA ASAP! :)


Ok awesome that we have progress. That confirms that the tweaks to the OVA config I made worked! So that's something and I can put that bit aside as "done"!

When do you see the login prompt?

As for the log in prompt. I assume that is after you've run through the firstboot scripts and set passwords, etc? In v16.0 it is expected behaviour for the firstboot questions to end with a screen that shows the network config, with an option to quit. (FWIW, that's Confconsole, but without the "Advanced" menu). This is an intentional change for v16.0, I'm happy to share the rational, take further suggestions and discuss possible improvements. But I'd rather resolve the issues as a priority and follow up on that later.

So do you see a screen with a "<Quit>" option, which then leaves you at the commandline login as per your screenshot, after selecting quit?

Or does it just dump you straight to the commandline login after doing the all of the firstboot scripts?

Or something else that I'm missing entirely?

No DHCP - useful info

The fact that you don't have a DHCP server is really valuable info! We'll do some further tweaking to Confconsole so regardless of the current system state, you can manually configure a static IP.

Although AFAIK even on previous TurnKey releases, it would have struggled with that scenario?!

Please run the following commands

What would be really useful is if you could please run the following commands from the commandline of this server (or a new one, if you've killed that one). You will need to log in as root and exit out of Confconsole if it starts. Then give me the output of the following 4 commands (screenshots are fine if that's easiest for you; you may need to take multiple ones to capture all the info from each of the commands):

route -n
ifconfig
systemctl status networking.service
journalctl -u networking

It would also be useful if you could share the actual VM networking info. I.e. a screenshot of the VMware network settings page for this particular VM. That way we can be sure it's set up as it should be, and we're recreating the same environment as best we can.


Dot point recap of what I need

  • Clarification on when you see commandline log in.
  • Output of the 4 commands I noted above.
  • Info on VM network config (from VMware VM settings - not from inside VM).

Plan moving forward

Regardless, we'll start make some more Confconsole tweaks and as soon as I have that additional info from you, I can do some final testing.

Considering the help you're giving us here, what I'll do next, is build an WordPress OVA for you to test (with all the tweaks to date included). I'll upload it to an alternate location as I can't "publish" it to our mirror without my colleague Alon's involvement (I don't have access to the release signing key), and waiting for him will be too slow). If that one "just works", you can continue to use that in production, even before we've "published" it - as it will be the exact same OVA! :)

bhruska's picture

You are welcome for the help.  

I'm going to run through it again to answer your questions as carefully as I can.

1. I deploy the OVA, and it completes successfully.
        - I included screen shots of the networking setup
        - This is exactly like my other VMs with the 14.0 version of Wordpress machine
2. I boot the machine
        - I do see a red message go by that say "failure" to bring up networking
3. A dialog prompts for a root password, which I supply
4. A dialog asks me to initialize Hub services, which I Skip
5. A dialog asks me for an email address, which I supply
6. A dialog asks me if I want to apply security updates, which I skip since I have no networking
7. Immediately after I close that dialog box, I get the TEXT prompt for the "core login:", asking for root usercode and password
8. Then it puts up a dialog saying "Networking is not yet configured"
9. I get into the networking dialog box, but the box for static IPs is scrambled, as per the screen shot
10. I can BACK out of that to the main setup dialog box
11. When I quit, it takes me to a root prompt
12. When I reboot, it reboots directly to the root login prompt, not the "normal" Turnkey menu

Note that there is an IndexError displayed after rebooting, and not showing the menu.

 

 

Note the error message above after rebooting.  No menu presented.

 

Thanks,

Brian

bhruska's picture

Don't forget this is the dialog box that's scrambled when asking for the static IP information.  I suspect this is just an error in a text file you've used to "describe" the dialog box and its fields.  Not sure what you use for those dialogs, but its probably something in the config for that dialog.

Brian

 

Thanks,

Brian

Jeremy Davis's picture

Please download and test this OVA:

http://download.jeremydavis.org/turnkey-wordpress-16.0-buster-amd64.ova

Note: this (same) WordPress OVA is now available from the mirror. The below hashes should still apply; or the signed hash file can also be downloaded from the mirror. (Those links are the same as the ones on the WordPress appliance page.)

Also here's the hashes:

sha256sum:

a1779e10aff41b8c28e34418ae2a334c83fae6bfa805e0d8d335eda895279fba  turnkey-wordpress-16.0-buster-amd64.ova

sha512sum:

416451c70e49c4f9da1ea44b4e92aae0899f708eb1ad506512ab067f6a99d1ba01702d94b194a40152c4d159d8bee038d66fdfabb54a6e63a24ed1e7f77ec2c5  turnkey-wordpress-16.0-buster-amd64.ova

Please let me know how that goes.

If it's still no good, them please let me know with as much detail re what doesn't work (with screenshots if possible) and I'll try again. Assuming I can work thought whatever issues may come up, I should be able to get another updated image up within 24 hours.

If it works (fingers crossed), you can continue using it if you wish. Alternatively, you can wait for the "official" one to be published to our mirror by early next week. Note that unless you tell me it's no good and we try again, this image will literally be identical to the one that we publish next week. I built this OVA on the TurnKey build infrastructure, just I uploaded it to a bucket in my personal AWS account (mapped to my domain) before my colleague Alon signed and published it to the TurnKey mirror (as I think I may have mentioned, I don't have the release key).

Jeremy Davis's picture

That's absolutely brilliant Brian! You rock.

My colleague Stefan has done some further Confconsole tweaks to support setting a static IP on an unconfigured interface. Armed with this extra info from you, I think that we can put together an OVA that will work!

No 100% promises, but I'll see if I can push out a new WordPress OVA for you to test today.

As you suspect, that "IndexError" appears to be related to the unconfigured interface. So what I've done for now, is just open an issue. It's ugly and we should handle it more gracefully, but so long as Confconsole can set a static IP on firstboot, you shouldn't hit that (unless you leave the network unconfigured). So I don't think that is a priority. Thanks for reporting though - a bug is a bug! :)

bhruska's picture

So we've gotten further.  I did get asked for a login/password after the dialogs asked for all of my passwords.  After entering that I got into the networking prompts.  It showed a strange dialog about the defaults, but after that I was able to enter a static IP address.  Not sure why the intermediate messages are necessary, but it went through okay.

After entering the networking info, I rebooted.  All looked good, but when the menu displays it falls through and doesn't stop at the prompt It just ends up at a root text prompt.  The screen show this pretty clearly.

I'll do some other checking, but I thought I'd pass this on right away.

Thanks,
Brian

AFTER DIALOGS FOR PASSWORDS:

 

 

WEIRD MESSAGE GOING INTO SET UP STATIC IP, BUT IT WORKED AFTERWARDS

AFTER REBOOTING, IT JUST FALLS THROUGH THE MENU

Thanks,

Brian

Jeremy Davis's picture

FWIW those warning messages are instead of the stacktrace. We might change them at some point, but essentially they're telling you that it can't automatically determine any networking info (that it was expecting to be able to automatically get). It sounds like you think they're redundant and/or not of any value, so perhaps we'll just get rid of them. Anyway, they're not doing any harm, so we'll leave them be for now.

Seeing that networking failed message there in the boot logs makes me think that perhaps we should be asking for (static) network config earlier though? I.e. a check to see if networking is working and if not give an opportunity to configure it before the end of that first sequence of questions?

Also the Webmin stopped/starting/started messages polluting the dialog screen are a little annoying. Unfortunately there's no way to suppress those messages without suppressing all of the startup messages (including the earlier ones) and they are really useful for diagnosing issues.

Still, solid progress...

Otherwise, this (i.e. what you've showed in this post) essentially looks usable. So that's a win IMO. - I'll respond to the other posts below

bhruska's picture

I like the new Webmin interface.  Its new to me anyhow.

I tried running the security update and got this error.

Also tried this:

Thanks,

Brian

Jeremy Davis's picture

So it looks like your server still has some networking issues?! On face value, these screenshots suggest to me that your server can't access the configured DNS server?! I.e. the nameserver you set in the networking config is either wrong, or unreachable.

Obviously you could start Confconsole again and use that to check/retry configuring the nameserver, but I think you might be best to stay on the commandline to diagnose this. That way we can rule out Confconsole as part of the issue. To check what nameserver is configured and if it's actually made it into the configuration in use:

First check the interfaces file (this is what Confconsole should be editing):

cat /etc/network/interfaces

Then what the system is actually using (this is configured dynamically, from the info in the interfaces file):

cat /etc/resolv.conf

FYI, here's the output from those commands on a system I have running that is working (actually the 192.168.1.5 nameserver doesn't exist, I just added that while I was testing, but as it only treats the second address as a fallback if the first doesn't respond, it doesn't matter in my case):

root@tkldev4 ~# cat /etc/network/interfaces
# UNCONFIGURED INTERFACES
# remove the above line if you edit this file

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
    address 192.168.1.154
    netmask 255.255.255.0
    gateway 192.168.1.1
    dns-nameservers 192.168.1.1 192.168.1.5
root@tkldev4 ~# cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 192.168.1.1
nameserver 192.168.1.5
options timeout:1

Now to test, I'm going to use ping to test those nameserver IPs. It's not conclusive as the nameserver may be configured to not respond to incoming ICMP packets (i.e. ignore ping) but it's worth a shot IMO. And assuming that you are using the same nameserver for other VMs then if you get no response here, you can double check from another one that is working.

root@tkldev4 ~# ping -c 4 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=20.8 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.428 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.419 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.489 ms

--- 192.168.1.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 43ms
rtt min/avg/max/mdev = 0.419/5.529/20.780/8.805 ms
root@tkldev4 ~# ping -c 4 192.168.1.5  
PING 192.168.1.5 (192.168.1.5) 56(84) bytes of data.
From 192.168.1.154 icmp_seq=1 Destination Host Unreachable
From 192.168.1.154 icmp_seq=2 Destination Host Unreachable
From 192.168.1.154 icmp_seq=3 Destination Host Unreachable
From 192.168.1.154 icmp_seq=4 Destination Host Unreachable

--- 192.168.1.5 ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 54ms
pipe 4

So in my case, 192.168.1.1 works fine (it's my local router provding gateway, DHCP & DNS - which forwards queries to the outside world). But 192.168.1.5 doesn't respond (no surprise as it doesn't exist).

I'd be inclined to check the settings of one of your other (working) servers and double check:

  1. That the nameserver IP is correct.
  2. That the netmask is correct.
  3. And if both of those are consistent, that the nameserver can be pinged.
If the netmask and nameserver IP are the same on both old and new servers, and the nameserver responds to ping on the old server, but not the new; then you still have networking issues. Assuming that the static IP you've set is a routable address within the network, then my guess is that it's some networking/routing issue outside of the new VM. Perhaps something within VMware? Or perhaps in your broader network?!
bhruska's picture

Wordpress has a Site Health Status feature that reports some modules missing from the PHP installation.  Is this something you should address for the wordpress build?

Thanks
Brian

 

Thanks,

Brian

Jeremy Davis's picture

Thanks for this note. I've opened an issue and we'll add those to the next release. Once you have the nameserver/networking issue sorted out on the server, then as noted on the issue, installing and enabling these should be pretty simple:

apt update
apt install php-zip php-imagick -y
systemctl restart apache2

FWIW, I just loaded this WordPress OVA into VMware Player (v15.5) and ran though these commands. It definitely removed that note and I couldn't see any other issues (at least not ones that make sense for us to do anything about IMO). So other than your DNS issues, it appears we may nearly be there for the initial OVA.


Also, outgoing networking is clearly working ok with this the new server! Otherwise you wouldn't have been able to access this WordPress page. I'm also assuming that WordPress is probably also reporting some other issues here too? As it wouldn't be able to resolve addresses via DNS either?! If it is, perhaps retry the previous apt commands? If it works now, that's great although I have no idea why it started working?!

bhruska's picture

I had my gateway IP with a wrong number in it, so that was why the updates weren't processing.  Duh.  Anyhow, it ran a bunch of updates.  Shouldn't the new OVA already have the updates in it?  I'll include the output from the update command at the end of this post.

I would take out the messages here.  Its just confusing.

 

I still don't understand why this can't boot cleanly into your menu.  I have to hit just the right keystrokes to get it to display correctly, otherwise I end up at the command prompt.  I think you will have people freaking about that.  It appears "broken".

Your commands worked to eliminate the Wordpress suggestions about loading the missing modules.  Hopefully you can just put that in the actual build.

 

Here's the output from the update command:


root@wordpress ~# turnkey-install-security-updates
+ SEC_UPDATES=FORCE
+ /usr/lib/inithooks/firstboot.d/95secupdates
Get:1 http://security.debian.org buster/updates InRelease [65.4 kB]
Get:2 http://deb.debian.org/debian buster InRelease [121 kB]
Ign:3 http://archive.turnkeylinux.org/debian buster-security InRelease
Ign:4 http://archive.turnkeylinux.org/debian buster InRelease
Get:5 http://archive.turnkeylinux.org/debian buster-security Release [3857 B]
Get:6 http://archive.turnkeylinux.org/debian buster Release [3830 B]
Get:7 http://archive.turnkeylinux.org/debian buster-security Release.gpg [833 B]
Get:8 http://security.debian.org buster/updates/main amd64 Packages [201 kB]
Get:9 http://archive.turnkeylinux.org/debian buster Release.gpg [833 B]
Get:10 http://security.debian.org buster/updates/main Translation-en [108 kB]
Get:11 http://deb.debian.org/debian buster/main amd64 Packages [7905 kB]
Get:12 http://archive.turnkeylinux.org/debian buster/main amd64 Packages [30.8 k                       B]
Get:13 http://deb.debian.org/debian buster/main Translation-en [5969 kB]
Get:14 http://deb.debian.org/debian buster/contrib amd64 Packages [51.0 kB]
Get:15 http://deb.debian.org/debian buster/contrib Translation-en [44.7 kB]
Fetched 14.5 MB in 4s (3585 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
The following packages will be upgraded:
  apt bind9-host libapt-pkg5.0 libbind9-161 libdns1104 libisc1100 libisccc161
  libisccfg163 liblwres161
9 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 5335 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://security.debian.org buster/updates/main amd64 libapt-pkg5.0 amd64 1                       .8.2.1 [966 kB]
Get:2 http://security.debian.org buster/updates/main amd64 apt amd64 1.8.2.1 [14                       18 kB]
Get:3 http://security.debian.org buster/updates/main amd64 bind9-host amd64 1:9.                       11.5.P4+dfsg-5.1+deb10u1 [271 kB]
Get:4 http://security.debian.org buster/updates/main amd64 libbind9-161 amd64 1:                       9.11.5.P4+dfsg-5.1+deb10u1 [247 kB]
Get:5 http://security.debian.org buster/updates/main amd64 libisccfg163 amd64 1:                       9.11.5.P4+dfsg-5.1+deb10u1 [266 kB]
Get:6 http://security.debian.org buster/updates/main amd64 libisccc161 amd64 1:9                       .11.5.P4+dfsg-5.1+deb10u1 [236 kB]
Get:7 http://security.debian.org buster/updates/main amd64 libdns1104 amd64 1:9.                       11.5.P4+dfsg-5.1+deb10u1 [1222 kB]
Get:8 http://security.debian.org buster/updates/main amd64 libisc1100 amd64 1:9.                       11.5.P4+dfsg-5.1+deb10u1 [457 kB]
Get:9 http://security.debian.org buster/updates/main amd64 liblwres161 amd64 1:9                       .11.5.P4+dfsg-5.1+deb10u1 [251 kB]
[master b3b37e1] saving uncommitted changes in /etc prior to apt run
 2 files changed, 7 insertions(+), 75 deletions(-)
 rewrite sysctl.conf (100%)
debconf: delaying package configuration, since apt-utils is not installed
Fetched 5335 kB in 1s (5709 kB/s)
(Reading database ... 34305 files and directories currently installed.)
Preparing to unpack .../libapt-pkg5.0_1.8.2.1_amd64.deb ...
Unpacking libapt-pkg5.0:amd64 (1.8.2.1) over (1.8.2) ...
Setting up libapt-pkg5.0:amd64 (1.8.2.1) ...
(Reading database ... 34305 files and directories currently installed.)
Preparing to unpack .../archives/apt_1.8.2.1_amd64.deb ...
Unpacking apt (1.8.2.1) over (1.8.2) ...
Setting up apt (1.8.2.1) ...
(Reading database ... 34305 files and directories currently installed.)
Preparing to unpack .../0-bind9-host_1%3a9.11.5.P4+dfsg-5.1+deb10u1_amd64.deb ..                       .
Unpacking bind9-host (1:9.11.5.P4+dfsg-5.1+deb10u1) over (1:9.11.5.P4+dfsg-5.1)                        ...
Preparing to unpack .../1-libbind9-161_1%3a9.11.5.P4+dfsg-5.1+deb10u1_amd64.deb                        ...
Unpacking libbind9-161:amd64 (1:9.11.5.P4+dfsg-5.1+deb10u1) over (1:9.11.5.P4+df                       sg-5.1) ...
Preparing to unpack .../2-libisccfg163_1%3a9.11.5.P4+dfsg-5.1+deb10u1_amd64.deb                        ...
Unpacking libisccfg163:amd64 (1:9.11.5.P4+dfsg-5.1+deb10u1) over (1:9.11.5.P4+df                       sg-5.1) ...
Preparing to unpack .../3-libisccc161_1%3a9.11.5.P4+dfsg-5.1+deb10u1_amd64.deb .                       ..
Unpacking libisccc161:amd64 (1:9.11.5.P4+dfsg-5.1+deb10u1) over (1:9.11.5.P4+dfs                       g-5.1) ...
Preparing to unpack .../4-libdns1104_1%3a9.11.5.P4+dfsg-5.1+deb10u1_amd64.deb ..                       .
Unpacking libdns1104:amd64 (1:9.11.5.P4+dfsg-5.1+deb10u1) over (1:9.11.5.P4+dfsg                       -5.1) ...
Preparing to unpack .../5-libisc1100_1%3a9.11.5.P4+dfsg-5.1+deb10u1_amd64.deb ..                       .
Unpacking libisc1100:amd64 (1:9.11.5.P4+dfsg-5.1+deb10u1) over (1:9.11.5.P4+dfsg                       -5.1) ...
Preparing to unpack .../6-liblwres161_1%3a9.11.5.P4+dfsg-5.1+deb10u1_amd64.deb .                       ..
Unpacking liblwres161:amd64 (1:9.11.5.P4+dfsg-5.1+deb10u1) over (1:9.11.5.P4+dfs                       g-5.1) ...
Setting up libisc1100:amd64 (1:9.11.5.P4+dfsg-5.1+deb10u1) ...
Setting up liblwres161:amd64 (1:9.11.5.P4+dfsg-5.1+deb10u1) ...
Setting up libisccc161:amd64 (1:9.11.5.P4+dfsg-5.1+deb10u1) ...
Setting up libdns1104:amd64 (1:9.11.5.P4+dfsg-5.1+deb10u1) ...
Setting up libisccfg163:amd64 (1:9.11.5.P4+dfsg-5.1+deb10u1) ...
Setting up libbind9-161:amd64 (1:9.11.5.P4+dfsg-5.1+deb10u1) ...
Setting up bind9-host (1:9.11.5.P4+dfsg-5.1+deb10u1) ...
Processing triggers for man-db (2.8.5-2) ...
Processing triggers for libc-bin (2.28-10) ...
Enumerating objects: 1622, done.
Counting objects: 100% (1622/1622), done.
Compressing objects: 100% (1127/1127), done.
Writing objects: 100% (1622/1622), done.
Total 1622 (delta 97), reused 0 (delta 0)
 

Thanks,

Brian

Jeremy Davis's picture

Ok, glad that the outgoing network issue was an easy fix! :)


Re the security updates, it's worth noting that the WordPress ISO was built nearly a month ago now. And the OVA is essentially a repackaging of the ISO. Ideally we try to keep them as close as we can and under normal circumstances, they would be built at the same time, so it would rarely be an issue. We've made something of an exception in an effort to resolve the issues that you've noted. And considering the OVA build lag, perhaps you're right and we should be installing these security updates at build time?! Actually, I might just do that...


Thanks for the feedback on those messages. We'll have to consider exactly what we do there. On reflection, I can see how they may be confusing, however, it's worth keeping in mind that by my understanding, your scenario (i.e. a network without a DHCP server) is not that common.

So in most cases, not having that base information (as automatically provided by DHCP) often correlates with network problems of some sort. So whilst I'm sure we could improve the message, I think that it might be wise to provide some note that we couldn't get DHCP info?! If you have any further thoughts on a message that conveys that info without being confusing, I'd be keen to hear.


When you say:

I still don't understand why this can't boot cleanly into your menu. I have to hit just the right keystrokes to get it to display correctly, otherwise I end up at the command prompt. I think you will have people freaking about that. It appears "broken".
I assume you're referring to the 3 Webmin stopped/starting/started messages polluting the console in your screenshot?

If so, does it only occur on firstboot? Or on all boots? Is it only ever those exact messages (i.e. those 3 stopped/starting/started Webmin messages)? Or is it sometimes other messages? After you clear it, does it occur again later? Or only when you reboot?

FWIW, in general unfortunately, that's been something of an issue since v14.x to a greater or lesser degree. It got worse in v15.x as systemd got better at starting services asynchronously. I did put a fair bit of time into trying to improve it for v16.0 and mostly IMO it is better than it was (both in v15.x and when I first started working on v16.0 - late last year). But short of suppressing all service messages (leaving just a blank black screen) I couldn't completely eliminate it. The messages give a sense of stuff happening and can be really useful for noticing and diagnosing issues so I'm loathe to suppress them.

If it is only Webmin, then perhaps there is something we can do specifically for that that we can improve? Regardless though, unless it's something specific to Webmin, I think we'e past the point of diminishing returns regarding stopping pollution of the console with late messages...


Re the php modules, yes as per the issue I posted earlier, they should be included in future WordPress appliance releases.

Jeremy Davis's picture

FWIW just reporting back that I noticed that the console of the VM I left running got polluted - and not just with Webmin related stuff as per your screenshot.

It's unfortunate but as I've already noted, I'm not really sure what can be done about it (without suppressing everything)...

bhruska's picture

The messages occur even after a reboot.  It gets to the config menu just fine, but then after a couple seconds it crashes out of the menu and I get the message that says 

[ OK ] Stopped Webmin Web based admin UI.
[ OK ] Starting Webmin Web based admin UI.
[ OK ] Started Webmin Web based admin UI.

At that point the screen is messed up.  Because the default answer is Quit, when I press enter it crashes out to the command prompt.  So to get the menu to display correctly, I have to press ESC, then say 'NO' I don't want to quit, then the menu displays correctly.  So this is clearly strange.

I do occationally see one red message when booting, but it appears and disappears so fast I can't tell what it is.  It does not always appear.  I've tried to capture it with print screen but I can't seem to.  Again, it doesn't always appear, and doeesn't seem to make any difference to the menu issue above.

Thanks,
Brian

 

 

Thanks,

Brian

Jeremy Davis's picture

The console pollution from service messages sucks and I'd really like to resolve it.

I'd also particularly like to investigate why it seems to consistently be Webmin that appears here in your screenshots?! I think that may actually be something else that could be improved. Whilst I was able to recreate the console pollution, it wasn't just Webmin for me and your screenshots suggest that's pretty consistent for you. That seems particularly interesting too as Webmin appears to be restarting when the appliance boots (I.e. "stopped", then "starting" and "started"). I'm unclear on why it would need to do that anytime other than on the firstboot?!

However, whilst it's ugly, may lead to some user confusion and/or concern, and as you note may lead to accidentally selecting "quit", primarily it's cosmetic. It's also worth considering that other than initial setup, most TurnKey users access the commandline via an SSH session (and these service messages only appear on the "primary console").

As you'd well be aware, we're still really behind schedule. We're still not quite halfway through the v16.0 full library release (about a third done so far; another ~60 to go). Plus I'm still yet to provide updated AWS Marketplace, Xen or OpenStack builds. And the Docker build also needs attention... As you've also pointed out, some of the appliances we've already published as v16.0, could benefit from a refresh/update. The list goes on...

Sorry to whinge...

Regardless, with all that in mind, I really need to prioritise finishing the v16.0 release. Once that's done, we can re-evaluate and decide what to prioritise next, probably bugfixing and updates and perhaps there'll be time to relook at this then?

bhruska's picture

How do you reload that menu if you accidentally quit?

Also, how do you reload the initial configuration menu that comes up upon install?

Are you going to have another OVA to test soon?  I know you said you are behind, and it sounds like I can use this one, but I was wondering if you've got one brewing soon.  I'm about ready to start rebuilding my five servers, likely later this week.

Thanks again,
Brian

 

Thanks,

Brian

Jeremy Davis's picture

To get that page back (well not exactly the same, but similar) log in within the terminal (username 'root' & the password you set on firstboot). On first terminal log in (local console, or SSH session), the full Confconsole will automatically appear (same as that page, except it will have an "Advanced" option rather than "Quit"). After the first log in it will just leave you at the terminal, but you can start it by running the 'confconsole" command (at noted in the MOTD).

If you wish to have it always auto start on terminal login, you can adjust that by editing the config file (/etc/confconsole/confconsole.conf) - make sure that the following is set:

autostart true

Note: no leading '#' !

I do hope to provide a Confconsole setting so the previous behaviour (i.e. launch to full Confconsole - with 'Advanced' menu on boot; rather than with just the "Quit" option) can be (re)enabled if you wish. In the meantime, you can manually do that yourself by editing the 4th last line in /usr/lib/inithooks/run. That line should currently read:

confconsole --usage

To get the "full" Confconsole on boot, just drop the '--usage' from the end, so it just says 'confconsole'; i.e. like this:

confconsole

Re a new OVA, I'm going to have to keep moving at this point so no there won't be a new one immediately. Hopefully, soonish I'll circle back and build an updated ISO, which will also mean a new (v16.1) OVA as well. But I need to get the rest of the v16.0 library published first (I'm nearly halfway through now).

However, one thing you could do to ease the roll out of your 5 servers is create your own "improved" v16.0 OVA! Then you can include things like:

  • Either (or both) of the options noted above.
  • Have the security updates (and other Debian packages too if you want) pre-installed.
  • Pre-install the PHP modules that we previously discussed (and any other pacakges you wish to have pre-installed).
  • Include other WordPress plugins and/or other WordPress customisations that you'd like.
  • Any other common configuration that you want for all your servers.

To do that, make all the changes that you'd like to a VM. You could use the one you already have running for tests, or you may prefer to launch a fresh one.

If you use the VM you have already, be sure that there are no additional users (Linux or WordPress) - i.e. ones that you may have created. So just leaving just the default 'root' Linux user and 'admin' WordPress user. Note that if you have additional user accounts other than the defaults, they will still exist in the new servers and will NOT have their passwords reset.

If you launch a fresh VM, be sure to make all the changes that you want to be common to all of your new servers. E.g. install the security updates, install the PHP modules, WordPress updates and any common plugins/modules you want installed. You may even want to install any/all of the available Debian updates?

Under normal circumstance, I'd recommend ensuring that you have DHCP networking enabled too (so you don't get an IP conflict). But seeing as you don't have a DHCP server on this network, that may be a bit of an issue... So you're probably best to just keep in mind that you'll need to manually change the IP when you start the new VMs - to avoid an IP clash.

Once you've done everything that you want to be in all your new servers (i.e. in the new OVA), edit the inithooks "defaults file" (/etc/default/inithooks). Make sure that the following is set (in your VM it should currently be 'false'):

RUN_FIRSTBOOT=true

That will make the firstboot scripts run on next boot, including asking all the questions, resetting the WordPress salts, auto-generating a unique DB password, etc.

Then shut the server down and "Export" it as an OVA. You can then use that new OVA as the basis for your new servers.

bhruska's picture

Okay, that's great info.  Thanks for taking the time to explain.  Good luck going forward.

Brian

 

Thanks,

Brian

Cyberben's picture

Right on!!

VMware Workstation  12 Pro - 12.0.1 Build 3160714

Smooth install, network adapter was found but down.

It began to work after I stopped the virtual machine and went to Edit > Virtual Network Editor and clicked "Restore Defaults". I then went back to the virtual machine's network adapter  settings and set it to Bridged as well as check marked "Replicate physical network status". I restarted the it and the network adapter was up. I also did the php-imagick commands previously mentioned. I had not used my VMware in awhile when I found LXC via TKLxc.

Pretty cool!

When can I bring it down to my TKLxc?   :)

Thanks! and Thank Again!!

 

Ben

 

 

 

Jeremy Davis's picture

TBH, I'm not sure why you had to fiddle with networking. The OVA should "just work"?!

Although it may be an issue between our config and your older VMware version? We've had some reports about networking issues with our v15.x VMs when upgrading VMware software. So we've erred on leaning towards the slightly newer virtual hardware for the v16.x release (it should "just work" on anything which VMware still lists as "supported" - note v12 "end of general support" was March 2019). TBH, trying to support the huge array of VMware software and versions can be a challenge...

Re your LXC question, technically it should already be available. And in theory it should work. But I'm not so sure in practice. Perhaps try specifying version '16.0' and see what happens? If you have issues getting the v16.0 WordPress LXC to work, probably best to start a new thread. :)

bhruska's picture

So now my wordpress is complaining I don't have PHP 7.4.  It appears to be less than a straightforward upgrade.  What's your understanding of 7.4, and the differences withe the latest Wordpress VM?

Also, have you found anything out about the console appliance menu mess after reboot?

Thanks,
Brian

 

Thanks,

Brian

Jeremy Davis's picture

As a general rule, I would avoid updating PHP unless you actually need to. FWIW you should expect WordPress and most plugins to support PHP7.3 for about a year and a half at least (when "official" PHP 7.3 security support ends). However, even beyond then, PHP 7.3 (as installed on TurnKey from Debian repos) will continue to get backported security updates from the Debian Security team until July 2022 (and then from the LTS team until June 2024) - see Debian wiki. WordPress itself should continue to work fine with PHP 7.3 indefinitely, although some plugins (especially smaller ones and/or less popular ones) may require newer PHP versions.

WordPress is known for supporting really old versions of PHP, so it's highly unlikely that you need a newer version of PHP for WordPress itself. Although as I hinted above, some plugins may drop support for versions of PHP unsupported by PHP themselves. So I would recommend doing some research whether any of the plugins that you use actually need a newer version (TBH, I'd be surprised if they do).

Regardless, it's your server. So if you really do want to update PHP (or you really do need it) then it's completely possible. You can install it via Ondřej Surý's third party PHP apt repository. He's a Debian Developer and a member of the PHP packaging team, so it a trusted source. The instructions on how to do that are noted in the README.txt within the repo.

However, it's worth keeping in mind that if you don't actually need PHP7.4, then you are better off sticking with PHP7.3 as provided by the default Debian repos. Because of the way that Debian manages security, we can safely configure TurnKey to auto install security updates. If you update to PHP7.4, then there is no longer a distinction between feature updates and security updates (all updates update to the latest version where security bugs are patched, but new feature bugs may be introduced). So automated updates are not recommended. That means that you will need to manually check for and install updates (via apt).

Re the systemd messages on the console. If you wish to disable them by editing /etc/systemd/journald.conf and uncommenting (i.e. remove teh '#' from the start) of this line:

#ForwardToWall=yes
Then change the 'yes' to 'no'. SO you end up with a line that looks like this:
ForwardToWall=no

PS apologies on such a slow response...

bhruska's picture

Great.  I'm still in the process of upgrading my servers to your new build, and this through me for a loop, and now I feel better with your explanation!  I appreciate the detailed explanation. It seems Wordpress should be a litle more careful with those messages.  Hope all is going well.

Thanks,
Brian

 

Thanks,

Brian

bhruska's picture

Any update on when the WordPress VM will support PHP 7.4?

WordPress is telling me to upgrade.

I've seen some directions for how to do this online, but I don't want to disable security updates, etc. if its not native.

Thanks,
Brian

Thanks,

Brian

Jeremy Davis's picture

We are currently working on v17.0 - which will include PHP7.4. Hopefully it will be released within the next few months. I hope to have an RC (release candidate) of Core within the next week or 2.

Having said that, PHP v8.0 is out already, so it will only be a few months before WordPress will start whinging about that instead... And then within another few months, v8.1 etc, etc. Once TurnKey v17.0 is released (with PHP7.4) it will likely be 2+ years before a newer PHP version will be included by default.

So you'll need to decide how you want to proceed.

If you want to follow WordPress's lead, then you can install the latest PHP from a third party. One of the lead PHP maintainers/packagers for Debian and Ubuntu maintains a PHP repository that I trust and works well. The downside of that is that you won't get automated security updates and will need to maintain that yourself. You could work around that by including the 3rd party repo in the daily updates, but each update is a new version, so there is always the risk of new bugs being introduced too.

OTOH, you could just use the default PHP and ignore the WordPress PHP version message(s) for now. Even though they recommend PHP 7.4, WordPress itself still supports PHP 5.6 so it's certainly far from a hard requirement. Debian supports the OS included PHP version with carefully crafted backported security patches. Even though upstream support for PHP 7.3 ends 1 Jan 2022, Debian (10/Buster) will continue to support the included PHP 7.3 until at least June, 2024 (and almost certainly longer).

Having said all that, where PHP version usually becomes an issue, is not with WordPress itself, but the plugins that you are using. The plugins too will require specific PHP version(s) and often their requirements are more limited than WordPress's. That can go both ways. E.g. a plugin maintainer might not have yet updated it to support a newer PHP version. Or they may drop support for an older PHP version (much) sooner than WordPress itself does. So the PHP version for plugins does matter! So you'll need to check what PHP version your plugins require.

Bottom line is that unless you need to update PHP version, I personally would hold off until we release v17.0. As I noted, that will include PHP 7.4 and will hopefully be available within the next couple of months. I'm more than happy to assist you to migrate your data. After that, when it starts nagging about PHP 8.0, you can decide which way to go from there.

For waht it's worth, I do hope to include a tool to easily change PHP versions in TurnKey. I started development of it quite some time ago, but hopefully it will be ready to include in v17.0. If not, I will release it ASAP.

Add new comment