Posts made by ronivay

@isener just run /opt/xo/xo-server/dist/recover-account-cli.mjs admin@admin.net

@isener said in Forgot password for the webgui:

and when I ping, I get:
ping: xo.my-company.net: Name or service not known

what is wrong?

There is no DNS record for xo.my-company.net or you can’t resolve it from wherever you’re trying now.

xo.my-company.net -> which ip address should this be:
of the xcp-neg server or the server where the xen-orchestar is installed?

from where to run this command:
xo-cli --register http://xo.my-company.net/api/admin@admin.net
the xcp-neg server or the server where the xen-orchestar is installed?

Answer to both would be where XO is installed.

@isener said in Forgot password for the webgui:

I read somewhere that yiu have to use this command in CLI
xo-server-recover-account youremail@here.com

but how to install CLI?

This does not mean you need xo-cli installed. CLI refers to just active shell to your XOA VM, via console or ssh. Just run the command in the shell. If you have XO from sources, there's no such command alias and you need to run the script directly from where your XO is installed, like <installdir>/packages/xo-server/dist/recover-account-cli.mjs

@julien-f haven't seen OOM's after this so looks good, thank you.

I'm running daily installation from sources on multiple different OS's. All have the same specs: 2vCPU/4GB RAM. This has worked flawlessly for a long time. Recently (starting from 4th/5th Nov) i've started to see OOM errors almost daily during yarn build which then cause it to fail with following error:

Using polyfills: No polyfills were added, since the `useBuiltIns` option was not set.
[01:23:25] Finished 'copyAssets' after 36 s
[01:24:33] Finished 'buildScripts' after 1.73 min
[01:24:33] Finished 'build' after 1.73 min
✖ 1
error Command failed with exit code 1.

It isn't consistent, sometimes it's debian that fails, sometimes ubuntu, sometimes centos/almalinux and so on. Something has definitely changed in the build procedure that eats more RAM than it used to.

I’m fine with increasing the RAM if needed. Just wanted to point this out if there’s something out of the ordinary with latest changes.

Settings -> audit. Assuming you have it enabled. If not, nowhere afaik.

Increasing VM disk size from XCP-ng center/XO only makes the block device larger, partition and filesystem (what you see in df output) won’t resize automatically, you need to do it manually inside the VM.

There’s usually little to no reasons to expose any mgmt systems to internet in actual production environments. Especially if it’s strictly for internal mgmt purposes. XO is no exception. Not because the system would be unsecure, but you simply want to make any attack surface as small as possible. It’s just a best a practice.

Okay, nodejs version is up to date then, so XO update will probably succeed as well without much of a hickup. Sure it’s safer if you can create a installation from scratch. XO gui has config export/import feature which you can use to migrate to new installation.

@JanP so you actually didn't update anything, probably just re-ran the installation on top of old codebase. See from sources installation instructions in: https://xen-orchestra.com/docs/installation.html#from-the-sources. Take note that it's perfectly possible that you also need to upgrade your nodejs version to latest LTS.

That'd be the first thing to solve as your installation is very old. It's therefore pointless to debug any issues until you get that XO to latest version as issue you're seeing could've very well be fixed long time ago.

So the answer is no, that is like couple years old. I assume it’s from sources installation then.

Start off by upgrading it to latest version. Instructed also here: https://xen-orchestra.com/docs/community.html

XOA or XO from sources? Is it up to date?

I’m still confused what is asked here and how it’s supposed to work NFS ISO repository works exactly as described, all hosts in the pool should be able to access it once configured (once), no matter how many hosts there are. For separate pools it needs to be added individually.

There are terms like remote and SR mixed here which have nothing to do with each other which is a bit confusing. Remote is a thing purely in Xen Orchestra and SR is something you configure to XCP-ng/Xenserver hosts via XO or other means.

I can reproduce same error with a fresh from sources installation when trying to add server.

Yup, installed nodejs version is beyond LTS version, which could be the cause. It is probably installed manually outside of the script as well since it installs 16.x if missing/too old but doesn’t do anything if version is above.

@vbits looks like you used XenOrchestraInstallerUpdater so i can just reply here.

If you used default user in the scripts config, you can put this timeout override config to /root/.config/xo-server directory and restart xo-server service. If you used other user than root, then same thing but /root -> /users/homedirectory

Sounds like a client side error if it happens with two different remotes on different systems, which probably explains why there’s nothing in server side logs.

Which OS is XO running? Could this be related: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949394

Could you try mv on smb share without XO involved to verify it’s not related? Sure it should report other than success if such renaming fails.

TrueNAS Core is the end result from FreeNAS (what it was called originally), which was always based on FreeBSD. It’s been around for years and has a solid foundation as a NAS OS.

Core and Scale look a like and share some components but under the hood they’re very different. Scale hasn’t been out there for long. Due to being Linux based it has more main stream features and will probably get much more in near future and evolve quicker than Core. For pure NAS usage, definitely go with Core instead of Scale for now.

CentOS 7 had missing lib dependencies already like 2 years ago which prevented xo-server to start. Just switch to a newer OS.

I can reproduce this (ref: https://github.com/ronivay/XenOrchestraInstallerUpdater/issues/133) and it seems to be caused by commit: https://github.com/vatesfr/xen-orchestra/commit/49890a09b7a3c4bcbe7f462577c6d0a7da8b7006

If you start from fresh (no redis database specifically) and install from that commit, or latest master, the default user creation doesn't work properly and above mentioned error is present in xo-server logs. It's actually all user creations (their passwords to be exact), not just default user. Doesn't affect existing users so if updating from previous version, everything seemingly works fine until new user is created and login with it fails.

If installing from commit: https://github.com/vatesfr/xen-orchestra/commit/dfce56cee8023ce0dc9292e0c1dda5e6937910e5 with fresh redis database, all works as it should. Also if broken admin@admin.net user was already created with installation from newer commit and redis database wasn't cleared, resetting user password with recover-account-cli.mjs in installation from this commit brings it back to life again.

rjlan created this issue in ronivay/XenOrchestraInstallerUpdater

closed invalid credentials on login to fresh install #133

0 julien-f committed to vatesfr/xen-orchestra

chore: update dev deps

0 julien-f committed to vatesfr/xen-orchestra

feat(async-each): add basic JsDoc typing

How should it work if job does not complete within the hour? If schedule would flex dynamically depending on last job completion time, wouldn’t it eventually be way off than actually scheduled?

In my opinion making hourly delta backups doesn’t make any sense and is something you should do in filesystem/file level inside VMs instead. Continuous replication and just snapshots should be fine, although the snapshot chain can easily grow too large and backups start to fail, so in that sense making snapshot rotation smaller would be better. Daily/weekly/monthly delta backup is understandable and makes perfect sense.