Dependencies for node-windows services - node-windows

I'm wondering how to define dependencies (other non node-windows nor node.js windows services).
In the code of winsw (HERE) I've found out it should be possible.
For me it seems to be a "issue" in node-windows as winsw can do it by adding following code to the service .xml file:
<depend>Eventlog</depend>

I think I got it, it's implemented but not documented (at least I didn't found it):
https://github.com/coreybutler/node-windows/blob/master/lib/winsw.js#L25
https://github.com/coreybutler/node-windows/blob/master/lib/winsw.js#L110
That brought me to the following (example) code:
var svc = new Service({
//...,
dependencies: [
'EventLog',
'W32Time'
]
});

Related

Nuxt3 Vite support for Cypress coverage instrumentation

I am building a Nuxt3 app and trying to integrate Cypress. As I'm aware Nuxt3 uses Vite instead and not babel, I was trying to instrument the project code using vite-plugin-istanbul npm package.
Here's my nuxt.config.ts after installing vite-plugin-istanbul package:
vite: {
vue: {
template: {
transformAssetUrls: true
}
},
plugins: [
istanbul({
exclude: ['node_modules', 'test/', 'coverage/'],
extension: [ '.js', '.ts', '.vue' ],
cypress: true
}),
]
},
When I'm trying to run the server using npm run dev and visit the localhost URL, the following error is thrown at terminal:
[nuxt] [request error] [unhandled] [500] window is not defined
at cov_1291n0zka8 (./.nuxt/dist/server/server.mjs:3623:191)
at $id_Sv05hbOoTf (./.nuxt/dist/server/server.mjs:3624:75)
at async __instantiateModule__ (./.nuxt/dist/server/server.mjs:40418:3)
It seems the plugin is instrumenting the server-side rendered code and window object isn't defined there. I need to have SSR enabled in my app and I'm not sure of how to handle this error.
This issue has been resolved by the plugin authors.
TLDR version
Just update the vite-plugin-istanbul package to the latest version and the issue should get resolved.
Long version
There are two parts to this error:
The package was originally configured to transform all the files. The plugin authors have now added a condition that checks whether the SSR has been enabled or not. This is done via options.ssr property within the transform function. Please upgrade to the latest version of vite-plugin-istanbul. The plugin no longer instruments the SSR files, hence the window object error no longer exists in there. Follow this thread if you need more details.
After getting this error resolved, I was still facing another issue where the code instrumentation was impacting the proper app compilation and throwing a hydration mismatch error. The plugin authors came to the rescue again and fixed this error. Please upgrade to the latest version of vite-plugin-istanbul. Follow this GitHub thread if you need more details.
The package authors are really awesome and helpful. It's great to see such people in the open source community!

Yocto parallel configuration packages files conflict

I have a base package that gives my functionality (wireguard-tools, taken from internet).
This package includes no configuration files for the network interfaces (as it should).
Then I created a few packages with this configuration files that are only to be deployed one for each respective image (e.g. image-1 includes wireguard-1-conf while image-2 includes wireguard-2-conf).
I would like to setup SystemD, but I can only do this when I have an interface configured, and it will only happen when the *-conf package is installed.
Unfortunately, the SystemD service file ("wg-quick#.service") is deployed by wireguard-tools package and my dependent package, the *-conf one, cannot see it:
ERROR: Function failed: SYSTEMD_SERVICE_wireguard-1-conf value wg-quick#wg0.service does not exist
I managed to do a dirty workaround but I feel dirtiest doing this in my *-conf recipe:
do_install_append () {
touch ${D}${systemd_system_unitdir}/wg-quick#wg0.service
pkg_postinst_${PN} () {
rm -f $D/${systemd_system_unitdir}/wg-quick#wg0.service
How should I proceed to make it work "the right way"?
Is there an elegant way of making "wg-quick#.service" from wireguard-tools accessible to *-conf?
Thanks in advance.
Additional Info
My *-conf recipes inherit systemd and include wireguard-tools dependency:
inherit systemd
...
DEPENDS_${PN} = "wireguard-tools"
RDEPENDS_${PN} = "wireguard-tools"
I so nothing else worth to mention in my recipes.

Yocto SYSTEMD_SERVICE to install a parameterized service ("#.service")

I need to configure WireGuard to bring up a VPN on boot on an Embedded Linux device.
My recipe installs a /etc/wireguard/wg0.conf pretty much like the examples found through the Internet.
Then I try to enable the service on SystemD like this on my wireguard.bb:
SYSTEMD_SERVICE = "wg-quick#wg0.service"
SYSTEMD_AUTO_ENABLE = "enable"
But bitbake throws me an error:
ERROR: Function failed: SYSTEMD_SERVICE_my-conf value wg-quick#wg0.service does not exist
I checked the temporary directory and file wg0.conf appears in the correct places but it seems that bitbake's SYSTEMD_SERVICE doesn't know how to expand the "wg0" after # sign.
If I try without the interface name (wg0):
SYSTEMD_SERVICE = "wg-quick#.service"
Bitbake is happy and finalizes my recipe, but it is not what systemd is expecting. Starting a service without an interface makes no sense...
Then I tried another approach and split the "wireguard" package itself from the configuration ("wireguard-conf" package) and added DEPENDS and RDEPENDS on "wireguard".
This got even worse since my wireguard-conf.bb recipe does not contain a "wg-quick#.service" file (it comes from the dependency "wireguard").
Well,
I don't know how to properly fix it and any suggestions will be highly appreciated.
Additional Info
I am using Yocto 2.0.3 in this project (with no hope of updating it).
Thanks to #TomasNovotny comments I managed to compare my "systemd.bbclas" against Github and noticed a change in systemd_populate_packages() that seems to solve the problem.
It works in newer OpenEmbedded (looks like in krogoth, version 2.1 released Apr 2016) and it is introduced by this commit. It works for me in rocko (version 2.4 released Oct 2017). According to j4x's comment, it doesn't work in jethro (version 2.0, Nov 2015).
For older (and currently unsupported OpenEmbeddeds) you can try to backport the patch or handle the symlinks for enabling the service in do_install().
Also please note that SYSTEMD_SERVICE_${PN} variable is package specific, so the _${PN} suffix has to be added (see manual).
I've also tried to enable OpenVPN with my profile (in Yocto rocko) without success.
Finally, I've made it working by providing OpenVPN recipe extension instead of custom one. So, the openvpn_%.bbappend file looks like:
inherit systemd
SYSTEMD_SERVICE_${PN} = "openvpn#clientprofile.service"
SYSTEMD_AUTO_ENABLE = "enable"
do_install_append() {
install -d ${D}${sysconfdir}/openvpn/
ln -sf /data/etc/openvpn/clientprofile.conf ${D}${sysconfdir}/openvpn/clientprofile.conf
}
As you can see, I'm using a symlink to my profile instead of the normal file. You can install a normal OpenVPN profile file instead of making symlink and it also works fine.

Mean.js - Dependancies Missing

I am using the MeanJS (https://github.com/meanjs/mean) framework, running on Heroku. When I try to run the application I get errors like:
Error: Cannot find module 'eslint-config-airbnb/legacy'
I am running in production mode (NODE_ENV=production).
The question I have is, it seems like gulpfile.js (when running the task prod) calls the task lint which calls the task eslint. But when I look at the packages.json file, I see that eslint-config-airbnb is only included in the devDependancies (and not dependancies). Now I tired to add it to dependancies, but I still get the same error about the missing module.
I'm new to MEAN.js, so I appreciate any help.

Make PHP on a Puphpet/Vagrant box use specific sub version e.g. 7.0.4 vs 7.0.5

Using puphpet a typical config.yaml php section might look like this:
php:
install: '1'
settings:
version: '70'
modules:
php:
- ioncube-loader
I have lots of other PHP modules installed but its ioncube I'm having issues with.
Up until just earlier, this was provisioning with PHP 7.0.4, which seemed to have a yum package for Ioncube loader.
I just had to rerun vagrant provision and now all of a sudden I appear to be on PHP 7.0.5.
Not much of a bother normally, except now I get issues with dependencies for ioncube (ioncube loader is crucial to run some encrypted 3rd party code I need).
My question is: Is it possible to lock php down to 7.0.4?
version: '704' doesn't work.
Also just to check I've understood the error message correctly:
Error: Package: php-ioncube-loader-5.1.2-1.el6.remi.5.4.x86_64 (remi)
Requires: php(zend-abi) = 20100525-x86-64
Installed: php-common-7.0.5-1.el6.remi.x86_64 (#remi-php70)
php(api) = 20151012-64
Available: php-common-5.4.45-5.el6.remi.x86_64 (remi)
php(api) = 20100412-x86-64
Available: php-common-5.4.45-7.el6.remi.x86_64 (remi)
php(api) = 20100412-x86-64
Available: php-common-7.0.4-1.el6.remi.x86_64 (remi-php70)
php(api) = 20151012-64
Available: php55u-common-5.5.33-1.ius.centos6.x86_64 (ius)
php(api) = 20121113-64
Available: php56u-common-5.6.19-1.ius.centos6.x86_64 (ius)
php(api) = 20131106-64
Available: php70u-common-7.0.4-1.ius.centos6.x86_64 (ius)
php(zend-abi) = 20151012-64
Other suggestions welcome, I just need ioncube loader working on this 1 project, am I right here? It looks like its available for every version of php except the one that's magically appeared on mine since the last provision. It's totally possible I'm barking up the wrong tree....
Author of PuPHPet here.
Unfortunately subversions are not supported (7.0.x), only major versions (7.0).
This is due to the absolutely insane way each distro and even each PHP version is so different to the other in regards to INI locations and module directories. It's ridiculous.
What could easily be added is support for ensure field to the YAML file that you could pass your specific version to. Mind opening a ticket on my github tracker to enable this?
hum
version: '704' doesn't work
should be
settings:
version: '7.0.4'
ioncube loader is not yet compatible with PHP 7, whatever version you install (7.0.4 or 7.0.5).
See the Compatibility list
Also see: upstream forum thread

Resources