TKL Odoo 17.1 seems to install properly from ISO but not from Turnkey Hub

[l-arnold]

Hi, I just ran through 2 installs on TKL Hub of TKL Odoo 17.1 but was never able to log in to Odoo or Debian (shell or webmin).

I did just pull down an ISO of the new Odoo and seem to have been successful using Virtual Box. Not sure what is not going through on the Hub but definitely cannot access.

When trying to install a New Database in Odoo as a workaround I am getting "Access Denied". It appears that the passwords set at launch on the hub are not taking w/ root, postgres and likely also with odoo.

Have killed both hub installs for now.

[JedMeister]

Hi Landis. Apologies for the slow response. It was going to be slow as I've been unwell, but also because I swear that I already responded to this the other day! (I notice that I applied tags 2 days ago, so that was likely when I thought I already responded). Clearly I must have neglected to click "comment"! Grr!

So, I tested myself and it seemed to work ok for me. Although I did use a fairly simple password.

We did have another Hub user the other day report that a password wasn't working. The password they were trying to use had a lot of "special characters" (i.e. punctuation marks). I confirmed that it was a problem, but never did get to the bottom of what the actual issues is. I do hope to circle back to it.

A work around for now would be to launch from the Hub setting not so great passwords, then log in via SSH. Obviously you'll need to either (preferably) set up a SSH keypair or set a not so complex root password (not recommended).

Then once you've logged in, run turnkey-init to reset better passwords.

PS I suggest setting up a SSh keypair and save the public one in the Hub - on the SSH keys page - then so long as you have your private key handy, you'll never need a SSH password again! :) Please be sure that you don't lose your private key though!

[l-arnold]

Ok. I will test again. Yes, was using somewhat complcated password but the approach has worked in the past. I'll get the keypair working again (generally just need to point to it I believe)

[l-arnold]

edit (nevermind).. Seems to have taken up the ODOO Settings upon Retry Will check if we can login after full install process. Updates running now.

Original comment below:

Just went to Hub.turnkeylnux.org try to install a server again again and I note that the general inithooks questions are not being asked regarding: posgres password odoo admin password

Only root is being asked. Seems to be for both 16.1 and 17.1 TKL versions for Odoo App.

The ISO was asking these things I recall and it seems should be on the hub.. particularly so that TKLBAM etc will work properly.

[l-arnold]

OK. Can log in in the various ways.

[JedMeister]

Hmm, that's interesting that the Odoo questions weren't originally showing in the Hub. I've actually come across that before too (not with Odoo but with something else). It's never happened before or since, so I thought it must have been a mistake on my end (e.g. perhaps accidentally trying to load Core or something?). But now you've mentioned it, I wonder if it really is a minor intermittent glitch?

[l-arnold]

Jeremy, I am reopening this. So 3 times in as many days now, I have not been able to login after creating to a Hub Created instance of Odoo TKL 17.1 - at least not using the passwords that I set up at creation. I did also set a Key and can get in via Putty. Found there I could use passwd root.. but the other day my Odoo Passwords were also not passing through. Right now I am trying a TKLBAM Restore (from 16.1) skipping database in hopes that that may set everything on one.

Was quite strange on another.. I swear I got a 17.1 to work but now when I see it on the web it is telling me it is a 16.1 install.

Anyway, Root Passwords are not going easily in with TKL Odoo 17.1 on the Hub. Ca

[JedMeister]

As I noted in my email to you, I did a test launch of a v17.1 Odoo appliance and it all appeared to work for me?!

I wonder if there is a character in your password that the Hub doesn't like? FWIW over the last couple of months, 2 others have reported issues with passwords set in the Hub not working (although on different appliances and retrying with a different password seemed to resolve it), so I'm thinking that there may be a character that is not being processed properly (either being misinterpreted - or perhaps being lost somewhere)?

I have some ideas on how I might be able to troubleshoot that, but I really need to understand which characters may be the ones causing the issue first (i.e. I need to be able to reliably recreate the issue). The other possibility is that it's a race condition of some sort. They are notoriously hard to diagnose, but I'll try to have a closer look ASAP.

As a workaround, if you can log in (via PuTTY) with your key, then you could try manually re-running the firstboot script(s).

You can rerun them all like this:

turnkey-init

Alternatively, you can just rerun the Odoo specific inithook like this:

/usr/lib/inithooks/bin/odoo.py

[l-arnold]

Thanks for the turnkey-init reminder..

So my current take is that "if left to sit" the Servers will eventually take the passwords that are given... but that is strangely after 24 hours or so.

I have done new Hub / Odoo installs with both Chrome and Firefox and they are not taking root passwords properly after first boot of Webshell or Webmin.

They are taking the assigned Cert and the turnkey-init will set them to properly (and immediately) take the passwords (yes, they can be turned off in SSH and it would be nice to have them be responsive to Certs in Webmin and Webshell - and not take passwords there, but that is a different subject).

It is a real bear getting Odoo DB's to move from TKL 16.1 to TKL 17.1... Working on a few of those again now.

To the "Issue at hand" though, the HUB is likely rebuffing more than me at first boot. Somewhere in this thread above I likely mentioned reboots (recall that anyway)... Not sure what is getting lost in the system.

[l-arnold]

The issue of starting a password with a symbol other than a letter or number continues in TKL 18 using the HUB. (Prestashop 18) Strangely also, putty did not take the certificate that I assigned. Unfortunately also Putty will time you out after only a few attempts then there is no way back in. I rebooted the server and still the same.

Also unclear as to whether I will be using admin or root to sign in... Killing the server but all this takes time.

[l-arnold]

V18 Admin paths (putty and webmin) are far too aggressive. in blocking access. Normally in the hub if I started with a "top line symbol" in a password, and it would not take in the hub, I could login via putty run turnkey-init and get everything to take. Putty is blocking still after 20 miniutes it seems. Now however, putty is not letting me in, nor even is webmin. I can browse the site. I can't log in as an administrator.
Tried Password Reset from the Administration Login but nothing yet after 5 miniutes. All I can seemingly do is either "wait", "reboot to the same" or "destroy the server".

This is TKL PrestaShop 18.0, fresh install Stopping next. Destroy most likely path but wanted to hang onto my tklapp sub..

[l-arnold]

Summary of what is known:

1: Don't start passwords with # or update the Hub to accept passwords starting with various "hashtags" Simply not doing so to start is a functional work around, then running turnkey-init to set them if needed.

2: Hub needs clear path to properly setting up Certificate files in V 18. Certs had worked in V 17 and below in the Hub. I should test on a new install, but given the rising cost of AWS it is critical to "get in and get out" .

3: Would be helpful to be able to set a Certificate that worked generically regardless of the Hub/AWS location.

[JedMeister]

Hi @l-arnold

Thanks for clarifying the issue re passwords. Great work! :)

Re your second point, do you mean SSL/TLS certs? If so, then provision of them has never been built into the Hub. However Confconsole should allow you to set up free Let's Encrypt SSL/TLS certs pretty easily.

Re your third point, relative to above, Confconsole should work fine with any domain, any host and location - even a locally hosted server that is not accessible via the internet. Although for servers not available online, you will need to use the DNS-01 validation method and use a custom domain where you can add a DNS record.

Although perhaps I misunderstand?

[l-arnold]

Clarification.
1: Really it would be great to allow the password types allowed on generic installs (ie from ISO and from turnkey-init) to also work on the HUB. Yes, I can simplify passwords but not my goal per say.

2: Certs did not work well in my one V18 test on the hub. In the past I could at least get in via putty if the password issue (1) messed up the hub install. From there I could run turnkey-init and reset.

3: Was not about Confconsole and I think "Putty Cert" and "SSL Certs" were crossed . I meant it would be great to specify a system wide (not just regional) "Putty cert" to any Hub server installed).

(Separate issue) I do appreciate your note about SSL/TLS Certs- I would love to have a way to get passed the html - insecure errors when locally hosted and not really able to pass the Let's Encrypt tests. I did not ask that but know that I did want to ask that. I have been adding entries to my "host" file to do local ip mappings, but it would be nice if SSL passed on those subjects.

[JedMeister]

@l-arnold - Thanks for the additional clarification. I have a few more questions/clarifications...

1: Really it would be great to allow the password types allowed on generic installs (ie from ISO and from turnkey-init) to also work on the HUB. Yes, I can simplify passwords but not my goal per say.

So the same password/s you had trouble (e.g. ones that start with #) work ok within the inithooks? But not from the Hub? If that's the case, then it's purely a Hub bug somewhere! At the very least it should give guidance on problematic passwords and not accept them on the launch server page.

If the password also doesn't work from the inithooks, then it's still a Hub bug, but it's also an inithooks bug. Both the Hub and the Inithooks should note chars that won't work and not allow them to be set.

Either way, it's an easy fix on the inithooks, but a tricky fix on the Hub. But we could at least give some notes about passwords that may be problematic...

2: Certs did not work well in my one V18 test on the hub. In the past I could at least get in via putty if the password issue (1) messed up the hub install. From there I could run turnkey-init and reset.

Oh, so you mean SSH keys? If so, then TBH, I'm not sure why that might be? I works ok for me, but perhaps there it's a curse of knowledge thing?

FWIW there are 2 ways that you can include SSH keys into a server launched from the Hub.

One is to use keys you already have configured in AWS. Select the desired key from the dropdown on the launch server page. In AWS keys are per region, so you can only use keys that are already configured for the region you want to use.

The other way is to add the desired (public) key/s on the Hub's SSH keys page. Any keys saved there will be included in any/every new server launched.

Also, PuTTY should work fine, although it's worth being aware that PuTTY uses a different key format. That's fine, but IIRC "normal" (i.e. "pem format") SSH keys need to be converted before they can be used locally with PuTTY - although I may be wrong there? Although I'm certain that if you generate a key pair locally with PuTTY, they need to be converted (to "pem format" before they can be added to AWS and/or the Hub.

Like I said, PuTTY is fine, but FWIW OpenSSH (what AWS uses, what I use and what all the servers have installed) can be installed in Windows: https://learn.microsoft.com/en-us/windows-server/administration/openssh/openssh_install_firstuse

3: Was not about Confconsole and I think "Putty Cert" and "SSL Certs" were crossed . I meant it would be great to specify a system wide (not just regional) "Putty cert" to any Hub server installed).

Ah ok. If I understand correctly, then as I noted above, SSH keys can be added to the Hub. Check out this page:

https://hub.turnkeylinux.org/profile/sshkey/

(Separate issue) I do appreciate your note about SSL/TLS Certs- I would love to have a way to get passed the html - insecure errors when locally hosted and not really able to pass the Let's Encrypt tests. I did not ask that but know that I did want to ask that. I have been adding entries to my "host" file to do local ip mappings, but it would be nice if SSL passed on those subjects.

Working SSL/TLS certs do depend on a specific domain name being resolvable. But the requirements are different, depending on the challenge/validation method you use.

For the HTTP-01 challenge type, the domain needs to be resolvable via DNS. I.e. the DNS record for your domain needs to point directly to your server and it needs to be public. If you use that, most routers these days should be smart enough to also connect you locally in that case.

If your server isn't publicly available and you use the DNS-01 challenge type, then you need to have full control of the domain. You need to be able to generate a specific DNS record to prove you control the domain. Assuming that Confconsole supports your DNS provider, once you have your relevant account set up (e.g. an API key) then confconsole should take care of that and it should "just work" - to get the cert/s.

If using the DNS-01 method to create the certs but the server isn't publicly avaialble, so long as you set a static IP for your local server, you could create a DNS record that points to the local IP. E.g. if you set your local server's IP as 192.168.1.100 and add that IP as an "A" DNS record. Even though you won't be able to access that domain outside of your LAN (because the it's not a public IP) inside your LAN it should "just work".

There are a number of other options/workarounds that you could look at too but I won't go into them here...

[l-arnold]

The password type does work with inithooks, just not with Hub. That is, it works with inithooks outside of the hub, or if, accessed via SSH-Keys, then running turnkey-init, even on the Hub it works. Basically the Hub Initialization seems to fail to give any access via the "at start" setup if a Hashtag is used.

SSH Keys, Not Cert s. Curse of Knowledge thing., you are right.. I will test again but also follow the link you provided. I think my suggestion was to do that installation "via the hub" rather than installing on the back end.

That particular Install in V18 referenced I was actually never able to access.

Good tip on using the different DNS methods Using an A method for a subdomain. Great pointer.

Thanks for all this Jeremy. Would love to dive into the Hub password issue sometime. Will "close with comment". Thanks again.

[JedMeister]

Odoo password

The password type does work with inithooks, just not with Hub. [...]

Ok, thanks for the clarification. I think we should open a separate issue tagged with hub for that. I'll probably do that shortly.

---

SSH login

SSH Keys, [...] I will test again but also follow the link you provided.

Thanks and please let me know if it doesn't work. This should perhaps be a separate issue, or at least a thread on the forums. Having said that, as this issue is closed now and we've already got the conversation going, we may as well keep speaking here.

Diagnosing the issue - step 1

If you install OpenSSH locally and it still fails, then please add the -vvv switch (makes the output super verbose) and share that output with me. If you are using another client, then please check their docs for how to get verbose output and share that.

Feel free to email it - ideally include the output as text copy/pasted into the email, but attaching a screenshot is acceptable. support AT turnkeylinux.org is the best email. I get a ton of emails via my personal turnkey.org email and emails sometimes get lost in the noise. IIRC you also have my personal (non work) email (which I won't post publicly) so that's an another option.

Diagnosing the issue - next step

Another thing we could try is giving me your public key - although please be sure that you share the public key only. Not the private one! Then I can try launching a server with your key and you can check if you can log in or not.

Diagnosing the issue - test SSH & fail2ban

Another thing we could check is if it's an interaction between our hardened SSH config & fail2ban.

FYI by default we limit the amount of times SSH will allow you to try to login in a single session to 3. I.e. it will try different log in methods 3 times in a single session. So historically (IIRC v16.x and earlier) whilst it may appear that it's allowing you to try over and over after the first 3 tries, it is actually closing your session. You can then try again (opening a new session). Whilst it wasn't noticeable to a human, it slows down malicious bots trying to brute force your password quite significantly.

So that in and of itself would unlikely block you as you can keep trying forever.

However as of v17.0 we also include fail2ban. That is a tool that keeps track of failed authentications and will block you for a certain time from retrying to login. IIRC it's 3 or 4 failed attempts and blocks you for 10 minutes by default. Again this slows down brute force attacks - albeit much more effectively.

The interaction between those 2 methods for blocking malicious actors, they can interact with one another and lock you out over and over again. For 10 minutes each time!

I can confirm that is the case with OpenSSH. These days with local test servers (which I can't/don't add my key to) I have to set a password at server launch and specifically use a password to log in. Otherwise I lock myself out. Assuming root user login - with OpenSSH that is done by:

ssh -o PubKeyAuthentication=no root@IP_ADDRESS

Although I'm sure that other SSH clients have similar setting. Probably...

Once I successfully log I disable that behaviour short term by stopping fail2ban (not recommended on a public server) or by updating the SSH config (much better on a public server).

On v18.x servers, edit /etc/ssh/sshd_config.d/turnkey.conf and adjust MaxAuthTries. IIRC in v17.x the file to edit is /etc/ssh/sshd_config (same config item).

---

Let's Encrypt

Good tip on using the different DNS methods Using an A method for a subdomain. Great pointer.

Check out these links for more details:

https://www.turnkeylinux.org/docs/confconsole/letsencrypt#http-01 https://www.turnkeylinux.org/docs/confconsole/letsencrypt#dns-01

---

Anyway, sorry for the essay! :)