@borzel only who do nothing can't do wrong. keep up with the good work and make treasure of your mistakes!
Best posts made by nackstein
-
RE: [WARNING] XCP-ng Center shows wrong CITRIX updates for XCP-ng Servers - DO NOT APPLY - Fix released
-
xe-guest-utilities on openSUSE
Hello,
I tried to install xe-guest-utilities on an openSUSE Leap 15.1. Here I will post a little patch and the procedure I followed if anyone want to replicate until openSUSE will be officially supported.
As root on the openSUSE VM:- mount the guest-tools.iso image in /mnt
- cp -r /mnt/Linux /root/
- cd in /root/Linux/ and apply this simple patch:
--- /mnt/Linux/xe-linux-distribution 2019-11-08 15:46:14.000000000 +0100 +++ xe-linux-distribution 2020-03-02 11:15:42.495364783 +0100 @@ -232,6 +232,7 @@ -e 's/^VERSION_ID="\([0-9]*\)\.\?\([0-9]*\)\?"$/major=\1;minor=\2;/gp' \ -e 's/^PRETTY_NAME="SUSE L\(inux\|INUX\) Enterprise \([a-zA-Z0-9_]*\) \([0-9]*\)\( SP[0-9]*\)\?"/_major=\3;_pretty_name=\0;/gp' \ -e 's/^SUSE L\(inux\|INUX\) Enterprise \([a-zA-Z0-9_]*\) \([0-9]*\) (.*)/_major=\3;_pretty_name="\0";/gp;' \ + -e 's/^PRETTY_NAME="openSUSE \([a-zA-Z0-9_]*\) \([0-9]*\)\.\([0-9]*\)"/_major=\2;_minor=\3;_pretty_name=\0;/gp' \ -e 's/^VERSION = \([0-9]*\)$/major=\1;/gp;' \ -e 's/^PATCHLEVEL = \([0-9]*\)$/minor=\1;/gp;' \ "${suse_release}")
- /sbin/insserv is required for the rpm install script so execute
zypper install insserv-compat
- run the install script
./install.sh
- now for some reason I ignore the script xe-linux-distribution inside the rpm is an older version than the one in the /root/Linux directory, for example it miss support for Sangoma Linux (FreePBX), this is just for the dev team, for our purpose we would anyway copy our patched version over the installed one:
cp xe-linux-distribution /usr/sbin/xe-linux-distribution
- enable the service and start it
systemctl enable xe-linux-distribution systemctl start xe-linux-distribution systemctl status xe-linux-distribution
on XO web console you should see the VM with version and the geko icon. So far the patch trick the system into belieaving that openSUSE is a sles distribution and so it assign the blu geko icon. In the future maybe openSUSE can be supported and the patch would be something like this:
--- /mnt/Linux/xe-linux-distribution 2019-11-08 15:46:14.000000000 +0100 +++ xe-linux-distribution.ng 2020-03-02 11:14:56.863364783 +0100 @@ -230,8 +230,9 @@ eval $(sed -n \ -e 's/^VERSION_ID="\([0-9]*\)\.\?\([0-9]*\)\?"$/major=\1;minor=\2;/gp' \ - -e 's/^PRETTY_NAME="SUSE L\(inux\|INUX\) Enterprise \([a-zA-Z0-9_]*\) \([0-9]*\)\( SP[0-9]*\)\?"/_major=\3;_pretty_name=\0;/gp' \ - -e 's/^SUSE L\(inux\|INUX\) Enterprise \([a-zA-Z0-9_]*\) \([0-9]*\) (.*)/_major=\3;_pretty_name="\0";/gp;' \ + -e 's/^PRETTY_NAME="SUSE L\(inux\|INUX\) Enterprise \([a-zA-Z0-9_]*\) \([0-9]*\)\( SP[0-9]*\)\?"/distro=sles;_major=\3;_pretty_name=\0;/gp' \ + -e 's/^SUSE L\(inux\|INUX\) Enterprise \([a-zA-Z0-9_]*\) \([0-9]*\) (.*)/distro=sles;_major=\3;_pretty_name="\0";/gp;' \ + -e 's/^PRETTY_NAME="openSUSE \([a-zA-Z0-9_]*\) \([0-9]*\)\.\([0-9]*\)"/distro=opensuse;_major=\2;_minor=\3;_pretty_name=\0;/gp' \ -e 's/^VERSION = \([0-9]*\)$/major=\1;/gp;' \ -e 's/^PATCHLEVEL = \([0-9]*\)$/minor=\1;/gp;' \ "${suse_release}") @@ -248,7 +249,7 @@ minor=0 fi - write_to_output "sles" "${major}" "${minor}" "${_pretty_name##*=}" + write_to_output "${distro}" "${major}" "${minor}" "${_pretty_name##*=}" } identify_lsb()
The above patch and procedure works for openSUSE Leap but not for Tumbleweed (the rolling version). I could write a patch for Tumbleweed but first would be better to find out why it does not boot after installation (get stuck on some disk procedure but systemd wasn't verbose enough and I didn't spent much time on it).
enjoy your openSUSE VM
Latest posts made by nackstein
-
RE: Stats Network throughput (b)its not (B)ytes
@noaks98 I agree that networking use bits per seconds and base 10 powers, the same for storage where the base 10 is the industry standard. Things change at the OS level, Linux stick with base 2 for almost anything, see df, memory pages etc.
If you look at the sar utilities even the network is reported with base 2 kilobytes.rxkB/s Total number of kilobytes received per second. txkB/s Total number of kilobytes transmitted per second.
looking at the code of sar (rndr_stats.c)
render(isdb, pre, PT_NOFLAG, "%s\ttxkB/s", NULL, cons(sv, sndc->interface, NULL), NOVAL, txkb / 1024, NULL);
I suppose that the "Linux" standard prevails here.
-
RE: [WARNING] XCP-ng Center shows wrong CITRIX updates for XCP-ng Servers - DO NOT APPLY - Fix released
@borzel only who do nothing can't do wrong. keep up with the good work and make treasure of your mistakes!
-
RE: Windows Time Sync
@gofm not sure on windows but on linux the walltime is written in UTC to the CMOS when you shutdown or when you explicitly call hwclock command. the time written in the virtualized CMOS should contain an offset to the host clock so when the VM start it read the host time plus the offset. I suppose that if you disable the time sync in windows, set the time and reboot you will come up with a correct clock.
I have no link to point you at, this is just a sum of things I remember but may be dated and/or wrong still if you can reboot your Windows VM could be worth testing. -
RE: XO Hub Template: what do you want next?
I noticed that the Alpine Linux 3.10 Template from the XO Hub have the parameter platform:viridian=true. Didn't notice any erratic behavior but just thought this could be a oversight.
-
RE: first attemp with XOCE
I tried building from scratch and with node 8. I had a couple of build error but building one package by directly entering its directory and relaunching building without --parallel in the main package.json solved my problem. I think the VM I used to build with 2GB RAM is not enough for parallel building (I took the hint from the post about building on FreeBSD).
now I would like to install on a local directory and not using the git directory to start services. how do you usually do in your development environment?
-
RE: first attemp with XOCE
@Danp oh yes, I just forgot to post it here. I'm going to edit my post. thanks.
I think the broken dependency is due to bcrypt 2.x that come only in 64 npm version and by using a too recent node/npm the build system look for bcrypt 2.x 79 npm version -
RE: first attemp with XOCE
@olivierlambert ok thanks for the clarification. I was deliberating exploring new territories. I don't like the build system in javascript but maybe it's useful on windows platform so you don't have to port make and shell script. to me it's a new complicated thing to just execute some command in a pipe. Anyway my post was sarcastic, I don't want to blame anyone.
-
RE: first attemp with XOCE
@BenjiReis yes but XOA is using v12.16.1 so I believed the documentation was a little old. I will try to build from scratch with the LTS that is 12.16.1.
-
RE: first attemp with XOCE
it seems that the git diff didn't include a modification I made, maybe the file isn't tracked.
in file @xen-orchestra/audit-core/node_modules/@babel/helper-compilation-targets/package.json
I had to modify the exports:"exports": { ".": "./lib/index.js" },
the original was like (not sure):
"exports": none
but was throwing error during build:
Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: No "exports" main resolved
-
first attemp with XOCE
hello all,
I tried following the instruction to install XO from source at https://xen-orchestra.com/docs/from_the_sources.html.
My target OS is a openSUSE 15.1. I start documenting the steps I followed, maybe can be of help to others:
I installed the prerequisites:zypper install -t pattern devel_basis zypper install redis git libvhdi-tools libpng16-devel python
I installed npm and node with the n script with a non root user (username xo):
curl -L https://raw.githubusercontent.com/tj/n/master/bin/n -o n N_PREFIX=/home/xo/ n latest
I installed yarn with xo user:
curl -oyarn-install.sh -L https://yarnpkg.com/install.sh ./yarn-install.sh
then as documented I cloned git and tried building with yarn:
git clone -b master http://github.com/vatesfr/xen-orchestra cd xen-orchestra yarn yarn build
then build process is much more complex than I expected (javascript dev are really crazy) and in my case it failed. I bonked my head against the wall trying to debug something I never saw. The major problem seemed to be babel that throw an OOM, at first I was thinking about bad libraries and regression but in the end I found out how to increase the heap of node. The other error seemed a regression in my node version, maybe I should switch to LTS instead of latest (I have installed 13.10.1).
I lost a lot of time trying different approach, I will post here just the solution for my case, it's not a patch for everyone:
diff --git a/package.json b/package.json index 9e44def0b..4d3be801d 100644 --- a/package.json +++ b/package.json @@ -60,7 +60,7 @@ }, "private": true, "scripts": { - "build": "scripts/run-script --parallel build", + "build": "scripts/run-script build", "clean": "scripts/run-script --parallel clean", "dev": "scripts/run-script --parallel dev", "dev-test": "jest --bail --watch \"^(?!.*\\.integ\\.spec\\.js$)\"", diff --git a/packages/xo-web/gulpfile.js b/packages/xo-web/gulpfile.js index 45feff969..6d32068d9 100644 --- a/packages/xo-web/gulpfile.js +++ b/packages/xo-web/gulpfile.js @@ -270,6 +270,7 @@ gulp.task(function buildScripts() { ) }) + gulp.task(function buildStyles() { return pipe( src('index.scss', { sourcemaps: true }), @@ -295,9 +296,14 @@ gulp.task(function copyAssets() { ) }) +//gulp.task( +// 'build', +// gulp.parallel('buildPages', 'buildScripts', 'buildStyles', 'copyAssets') +//) + gulp.task( 'build', - gulp.parallel('buildPages', 'buildScripts', 'buildStyles', 'copyAssets') + gulp.series('buildPages', 'buildScripts', 'buildStyles', 'copyAssets', function (done) { done();}) ) // ------------------------------------------------------------------- diff --git a/packages/xo-web/package.json b/packages/xo-web/package.json index 57c99d193..e6530a154 100644 --- a/packages/xo-web/package.json +++ b/packages/xo-web/package.json @@ -148,7 +148,7 @@ "xo-vmdk-to-vhd": "^0.1.8" }, "scripts": { - "build": "NODE_ENV=production gulp build", + "build": "NODE_ENV=production gulp build --max-old-space-size=1024", "clean": "gulp clean", "dev": "NODE_ENV=development gulp build", "prebuild": "yarn run clean && index-modules --auto src",
probably you can avoid the serialization in the gulpfile, I used it to debug.
who on earth wrote a build system in javascript? IMHO Satan himself.anyway, I reached the end and the build was successful, I just ignore a couple of optional dependencies that does not work, I just remember one is bcrypt, I forgot the other and don't know how to recheck.
now it's as simple ad creating a configuration (default) for redis and start it. and then start yarn.
for the start I have to switch to root, I wanted to try with xo user but I see that the at the start xo-server look for a lot of command requiring root privileges, I wasn't in the mood of hacking to wrap all of them with a sudo script. I don't know if there is a smarter approach. so as root I loaded the PATH variable to look for the yarn and node binaries and with yarn start all works. login ok and first round clicking between webpages all ok.now one question, how do you export the built application to /usr/local or /opt or other directory to actually make an installation? I don't see any procedure. I suppose I have to copy the packeges directory in place. it's so?