Hi Julien, i already did that. localadmin is the user i also use for the xo-server. did not elaborate that further on a test system.

node is still 8

localadmin@xoa:/var/log$ node -v
v8.16.1

I used this, unchanged, non root and port to 1024
https://xen-orchestra.com/docs/from_the_sources.html
no auto upgrades on debian

edit:

localadmin@xoa:/var/log$  cat /etc/debian_version
9.11
localadmin@xoa:/var/log$ node -v
v8.16.1

hi,

built my self a xo from source, playing around a bit.

i am not locked out from the webUI, but i tried to ./xo-server-recover-account admin@admin.net just to see if it works, this is what happens:

localadmin@xoa:/opt/xen-orchestra/packages/xo-server/bin$ sudo ./xo-server-recover-account admin@admin.net
Password (leave empty for random): ********
✖ Cannot read property 'listingDebounce' of undefined
TypeError: Cannot read property 'listingDebounce' of undefined
    at new metadataBackup (/opt/xen-orchestra/packages/xo-server/dist/xo-mixins/metadata-backups.js:104:62)
    at new Xo (/opt/xen-orchestra/@xen-orchestra/mixin/dist/index.js:90:29)
    at /opt/xen-orchestra/packages/xo-server/dist/recover-account-cli.js:43:16
    at Generator.next (<anonymous>)
    at asyncGeneratorStep (/opt/xen-orchestra/packages/xo-server/dist/recover-account-cli.js:18:103)
    at _next (/opt/xen-orchestra/packages/xo-server/dist/recover-account-cli.js:20:194)
    at <anonymous>

am i doing it wrong? doing it as root gives the same message. I can change the password in the WebUI just fine.

syslog and messages do not give me anything interesting regarding this, orchestra.log gives me this:

2020-03-09T08:45:04.176Z app-conf /opt/xen-orchestra/packages/xo-server/config.toml
2020-03-09T08:45:04.177Z app-conf /opt/xen-orchestra/packages/xo-server/.xo-server.toml
2020-03-09T08:45:04.192Z xo:main INFO Configuration loaded.
2020-03-09T08:45:04.201Z xo:main INFO Web server listening on http://[::]:1024
2020-03-09T08:45:04.320Z xo:xo-mixins:hooks DEBUG start start…
2020-03-09T08:45:04.372Z xo:xo-mixins:hooks WARN hook start failure: { error: 
   { Error: spawn losetup ENOENT
    at Process.ChildProcess._handle.onexit (internal/child_process.js:190:19)
    at onErrorNT (internal/child_process.js:362:16)
    at _combinedTickCallback (internal/process/next_tick.js:139:11)
    at process._tickCallback (internal/process/next_tick.js:181:9)
     errno: 'ENOENT',
     code: 'ENOENT',
     syscall: 'spawn losetup',
     path: 'losetup',
     spawnargs: [ '-D' ],
     stdout: '',
     stderr: '',
     failed: true,
     signal: null,
     cmd: 'losetup -D',
     timedOut: false,
     killed: false,
     [Symbol(originalCallSite)]: [ CallSite {}, CallSite {}, CallSite {}, CallSite {} ],
     [Symbol(mutatedCallSite)]: [ CallSite {}, CallSite {}, CallSite {}, CallSite {} ] } }
2020-03-09T08:45:04.416Z xo:xo-mixins:hooks DEBUG start finished

oh thank you, did not see that

Hi,

been playing a bit with the Backup NG, i kind of miss the possibility of doing different jobs on weekdays than on the weekend...

like for example, i want to backup a fileserver each weekday with a retention value 2 but on saturday, sunday stop that to have the network and remote storage ready for the regular backup jobs.

This is for emergency scenario, the backups on the local storage are done with snapshots.

i miss the day-of-week ( dow ) setting that i have in cron, can i make the job wth a schedule and then change the schedule in crontab?

ok, logged into linux, su root, and tried the command on the console

 mount -t nfs 192.168.30.60:/mnt/Brutus/Remote /run/xo-server/mounts/86109d77-9600-48c6-b131-0ca475cd1ad4 -o vers=3
mount.nfs: requested NFS version or transport protocol is not supported  

tried without -o vers=3 and it worked.

Hello Forum,

community edition, test system.
i was rearranging my Nas, so i disconnected the Remote i used for Backups, made a Raid10 instead of Raid5 ( speed ) and recreated the shares.
the backups were not important, was just a test.
now when i tried to reconnect the remote ( same share name, same server ) it said

remote.test
{
 "id": "bb4532ab-12a7-4103-9420-7847da8ca9ff"
}
{
 "errno": -17,
 "code": "EEXIST",
 "syscall": "mkdir",
 "path": "/run/xo-server/mounts/bb4532ab-12a7-4103-9420-7847da8ca9ff",
 "message": "EEXIST: file already exists, mkdir '/run/xo-server/mounts/bb4532ab-12a7-4103-9420-7847da8ca9ff'",
 "name": "Error",
 "stack": "Error: EEXIST: file already exists, mkdir '/run/xo-server/mounts/bb4532ab-12a7-4103-9420-7847da8ca9ff'"
} 

i destroyed the remote now and made it new, only to see

remote.test
{
  "id": "86109d77-9600-48c6-b131-0ca475cd1ad4"
}
{
  "code": 1,
  "stdout": "",
  "stderr": "mount: only root can use \"--options\" option
",
  "failed": true,
  "signal": null,
  "cmd": "mount -t nfs 192.168.30.60:/mnt/Brutus/Remote /run/xo-server/mounts/86109d77-9600-48c6-b131-0ca475cd1ad4 -o vers=3",
  "timedOut": false,
  "killed": false,
  "message": "Command failed: mount -t nfs 192.168.30.60:/mnt/Brutus/Remote /run/xo-server/mounts/86109d77-9600-48c6-b131-0ca475cd1ad4 -o vers=3
mount: only root can use \"--options\" option

",
  "name": "Error",
  "stack": "Error: Command failed: mount -t nfs 192.168.30.60:/mnt/Brutus/Remote /run/xo-server/mounts/86109d77-9600-48c6-b131-0ca475cd1ad4 -o vers=3
mount: only root can use \"--options\" option

is this expected behaviour, does the xo vm need a reboot between this operations?

@olivierlambert
yes it was the juniper, had to search a while... and then create xoa-dl as application with tcp 8888 and add it to the zone policy of that VLAN. Juniper cli is a bitch.
works now. thank you.

@olivierlambert oh so there IS something wrong on my side, thanks.
i will check with the firewall

i was sticking to the https://xen-orchestra.com/docs/xoa.html doc.
i have to get the appliance directly to the xcp server because a ssh console on the xcp is all i have, no gui or anything, thats why i try xoa so i have a gui... 80 and 443 are free through the vpn as well.

getting the xva here and then send it there is no option, only have about 7Mbit net through the vpn here and gigabit internet there....

i remember this worked on my first test install, thats why i sticked to it

hi, i tried

curl -sS https://xoa.io/deploy | bash

to install a xo appliance as mentioned here
https://xen-orchestra.com/docs/xoa.html

but it just stopped after a while without any change.

[root@vhrz01 ~]# curl -sS https://xoa.io/deploy | bash

Welcome to the XOA auto-deploy script!

Network settings:
Importing XOA VM...
[root@vhrz01 ~]#

is that a known bug or something wrong on my side?
after looking into the script i tried

xe vm-import url=http://xoa.io:8888/

directly ...
the task stays on 0% for a while and then breaks off with

The server failed to handle your request, due to an internal error.  The given message may give details useful for debugging the problem.
message: Unix.Unix_error(Unix.ETIMEDOUT, "connect", "")

i tried a telnet xoa.io 8888 but it seems the port is closed.
alex

hi,

i installed myself a xo community edition, great tool.
worth mentioning:
when trying to make a remote for the backup, it fails with

EACCES: permission denied, mkdir '/run/xo-server'

in the webgui.

su root
mkdir /run/xo-server
chown /run/xo-server yourusernamehere:yourusernamehere

changes the error message in the gui to

Command failed: mount -t nfs 192.168.30.60:/mnt/Brutus/Remote /run/xo-server/mounts/bb4532ab-12a7-4103-9420-7847da8ca9ff -o vers=3
mount: only root can use "--options" option

when nfs-common is installed ( which should ) then i can mount the remote as root in the terminal with the command from the message.

works then, but when restarting the xo-vm the mount is gone.

i did a dirty workaround and scripting that when starting the vm.
is there a "clean" solution?

thank you, that did it.

i got the container plugin installed, shows the containers in the VM fine in XO, testing migration of that VM now

migration fails, hangs at 90%. rebooting and hard reboot hung in task list. how to kill?

[root@vhrz01 log]# xe task-list
uuid ( RO)                : ff33a962-baaf-d48d-409f-f2f0e2da0dac
          name-label ( RO): Async.VM.hard_reboot
    name-description ( RO): 
              status ( RO): pending
            progress ( RO): 0.000


uuid ( RO)                : c0a304ed-bea3-fc81-0ad8-d54d823b5ba3
          name-label ( RO): Async.VM.clean_reboot
    name-description ( RO): 
              status ( RO): pending
            progress ( RO): 0.000


uuid ( RO)                : ddac4b61-86b6-87f1-e035-35bd35493131
          name-label ( RO): Async.VM.pool_migrate
    name-description ( RO): 
              status ( RO): pending
            progress ( RO): 0.900

Tested with Chrome now, on chrome it works. So it seems only a firefox problem.

I switched off the extensions ( https everywhere, ublock origin and privacy badger ) but still crashes.

Had htop running on my client while crashing, no unusual increase in RAM usage while going to crash.

Rebooted XO VM, now it is ok again with firefox.

so for me the issue is closed, if somebody is bored and wants to look into some logs for bug hunting i am glad to provide them.

i also restarted the toolstack on one of the pool members ( not master ) and the "no such host" error is gone.

Hi Forum,

My firefox is crashing with the XO Gui when looking at the logs.
Had a look in the /var/log

my orchestra.log is clogged with

2019-12-10T08:28:29.642Z xo:api WARN admin@admin.net | pool.listMissingPatches(...) [5ms] =!> XoError: no such host 558e41cc-598a-4686-8c71-0da4c47f5a9a

every five seconds.

Most probably it is an old xen server i had in there ( playing with this a lot right now, 2 pools at the moment ), but i seem to be unable to find the old entry. Pools seem to be fine from the xcp side...

it´ s on a "from source" build on a debian VM.