MeshCommander on Linux

[veitw]

Hey guys,

currently, only the Windows standalone app version of MeshCommander is fully featured, essentially we are missing the built-in CA and the possibility to connect to a MeshCentral server, required to roll out mescripts to a lot of devices (some CIRA) at once.

Will the NW.js based standalone version of MeshCommander with full features be available for other platforms in the foreseeable future (here: for Linux)?

Is there documentation on how to build the MeshCommander standalone that we could start with to try ourselves?

Until now I only found this chap's efforts to bring MeshCommander to the Mac world but the repo it seems unmaintained and is almost as outdated as it is homebrewy.

Best regards, // Veit

[Ylianst]

So, MeshCommander comes in different versions (".msi", "npm install meshcentral", one you can load in Intel AMT firmware...). The nice one for Linux is the NPM one, it creates a small web server on port 3000 and you should be able to use it from any browser. I think it includes setup.bin support, but you right that it's not complete. It does not have Intel AMT network scanning for example. I could add it, but I am swamped with projects.

Because MeshCommander is a nw.js application, you can install it on Windows, download nw.js for Linux and move the right files over and it should start up on Linux. I have never deployed software on Linux and so, I am a bit clueless on how I could do that. I guess I could bunch nw.js + MeshCommander in a zip file? The only thing that will be weird in that the Linux version needs to use the JavaScript IDER library, not IMRSDK.dll. Except for this, it should work just fine on Linux nw.js.

[veitw]

Because MeshCommander is a nw.js application, you can install it on Windows, download nw.js for Linux and move the right files over and it should start up on Linux.

I tried this and I was widely successful. After a quick check I found only few issues:

1. The MeshCentral login screen has a non-working image although working under Windows, a common cause may be using \ instead of / as path separator:

2. There is a line break for every item in the devices list, maybe caused by rendering differences due to my much more recent version of NW.js, or maybe differences in font rendering on Linux:

3. As you already mentioned, IDER is not working as it tries to load a Windows binary for binding the imrsdk.dll into node:

I have never deployed software on Linux and so, I am a bit clueless on how I could do that. I guess I could bunch nw.js + MeshCommander in a zip file?

I am quite familiar with packaging for RPM-based Linux distributions and I could provide you with a simple RPM spec file that uses such a ZIP archive to build a RPM package that should just install on allegedly any RPM-based distro (architecture depending on which NW.js binary is dumped into the ZIP, but x86_64 should suffice to reach almost all users) such as Fedora, RedHat Enterprise Linux, CentOS, SUSE Linux Enterprise Server, openSUSE, ... which nicely integrates into Linux desktops.

If you want, I may also build this and future packages, but I think better someone officially associated with the project should do that as a matter of trust and security.

After such a meshcommander.spec file has been put into the ZIP, you may simply run this command on a RPM-based distro of your choice with rpmbuild and unzip installed and issue this command:

$ rpmbuild -tb meshcommander-0.8.9.zip

rpmbuild will then create e.g. meshcommander-0.8.9-1.x86_64.rpm that will be ready to install.

Note: rpmbuild -t actually expects a tarball, not a zip, so maybe you need to put it into a tar archive instead. I will check that if required.

Alternatively, one could put a slightly more complicated meshcommander.spec file into the rpmbuild SPECS directory and a MeshCommander ZIP without NW.js as well as the archives of NW.js binary builds for different architectures into the rpmbuild SOURCES directory and run

$ rpmbuild -bs meshcommander.spec

which would then create a source RPM, e.g. meshcommander-0.8.9-1.src.rpm containing MeshCommander and the different NW.js packages.

Now you could create RPM packages for different architectures using e.g.:

`$ for i in x86_64 i386 armv7hl; do rpmbuild --rebuild --target=x86_64 meshcommander-0.8.9-1.src.rpm; done

It needs to be mentioned that using binaries to build RPM packages is often regarded bad style, but the effort to build NW.js and node from source just to bundle MeshCommander might be just too much.

After building an RPM, one might use alien to convert it to other packaging formats such as .deb for dpkg based distributions such as Debian, Ubuntu etc. But similar to putting a spec file into the archive, maybe someone else could create a debian subdirectory which will allow to build deb packages directly from the ZIP as well.

Other options could be more or less distribution independent packaging formats such as AppImage, Flatpak or Snap which allow to run the application either directly from a single binary file or to install into and run from an application container.

[Ylianst]

Nice! I should be able to fix the image/breaks/IDER in the current code without breaking the existing Windows MeshCommander. Let me take a short at that.

[Ylianst]

Just updated MeshCommander.msi and source package with a few fixes for the latest NW.js. I did not see a problem with the MeshCentral50.png image, make sure it's in the "images-commander" folder.

I did not change the version of the .MSI file, it's still v0.7.9. You can uninstall/downloads/reinstall. If you right click on the .msi properties in Windows, you will see it's signed with today's date. Can you give it a try? breaks should be fixed and IDER should fall back to the JavaScript IDER library when running on non-"win32" platform.

[Ylianst]

Oh, the problem with the image is that you need to rename "meshcentral50.png" to all lower case.

[veitw]

Hi @Ylianst,

as promised, I have created a RPM spec file for MeshCommander.

Unfortunately I learned that nwjs.io offers official NW.js binary bundles only for i386 and x86_64 Linux, but not for other architectures, so using the prebuilt bundles we may not create packages for e.g. Raspberry Pi. Because of this and as x86_64 is the standard case on the Linux desktop and more and more distributions are dropping i386 support, I decided a spec file with binary architecture switch would just make it more confusing and created a x86_64-only spec file.

Using this spec, it is possible to directly fetch both the MeshCommander Windows MSI and a NW.js tarball binary from their websites and build a RPM package in seconds. As the MeshCommander MSI download filename does not contain a particular version, it is important to take care that the download matches the version number in the spec file. If a new RPM is built from the same version, one needs to increase the release number (and to reset the release to 1 for the first package of a new version).

The spec file includes all instructions to clean up the Windows build to the best of my knowledge and to transform it into a nice Linux application.

I created and tested the spec on Fedora, but I expect it to run well on other RPM based distros as well as I am positive that it does not utilise distro specifics. I installed and ran the application from the resulting package on Fedora 30 as well as CentOS 7.7 and they worked fine. I only noticed a minor problem on CentOS 7; the GNOME desktop shows a default icon instead of the MeshCommander icon. This is because of the quite outdated GNOME desktop on CentOS 7 that expects icon filenames to have a file extension, while more recent desktops want only the base name and load the icon with the extension that matches the display purpose best. As this is jsut a cosmetic problem and also CentOS 8 is already out and comes with a much more current version of the GNOME desktop, I think that this does not justify to maintain two versions of the package.

To use the spec file to build a RPM package, you need:

1. A RPM based distro. I am using Fedora 30 here. If using an older version of Fedora or an Enterprise Linux (clone) older than 8, substitute "dnf" with "yum".
2. Create a user for RPM packaging, I will name it "build" here. It is strongly recommended to not use root for package building. sudo adduser build
3. Install rpm-build and rpmdevtools. rpm-build is required to build RPM packages, rpmdevtools contains the tools we use later to create the RPM build tree and to automatically download sources. sudo dnf install rpm-build rpmdevtools
4. Install the spec file's build dependencies; ImageMagick and msitools. msitools is required to extract the files from the MeshCommander.msi, ImageMagick is used to create a PNG desktop icon image from MeshCommander's favicon.ico. sudo dnf install msitools ImageMagick
5. Switch to the build user. sudo su - build
6. Create a "rpmbuild" directory tree in the build user's home directory using rpmdev-setuptree. rpmdev-setuptree
7. Copy the meshcommander.spec file in the build user's home directory. You may want to make it writable to be able to edit it in the future. (The usual place for spec files would be ~/rpmbuild/SPECS, but placing it in ~ works, too, and is maybe easier to maintain.)

Now you have your RPM build environment and can start building RPM packages:

0. Edit meshcommander.spec to match MeshCommander's current version.
1. Run spectool to automatically download both the MeshCommander.msi and the NW.js binary tarball. spectool -g -f -R meshcommander.spec The -g flag tells spectool to download the source files, -f tells it to force downloading (this is required as MeshCommander.msi does not contain a version number, thus needs to be replaced even if it already exists), -R makes spectool place the downloaded files in ~/rpmbuild/SOURCES, where rpmbuild expects to find them.
2. Build the MeshCentral RPM. rpmbuild -bb meshcommander.spec -bb is build binary. Alternatively you may want to use -ba instead to have rombuild also build a source RPM file, which contains the specfile and the downloaded source files and may be used to build RPMs using rpmbuild --rebuild.
3. The new RPM package file is placed in ~/rpmbuild/RPMS/x86_64 . If your system is a desktop installation, you may now install it using e.g. sudo dnf install /home/build/rpmbuild/RPMS/x86_64/meshcommander-0.7.9-1.x86_64.rpm and distribute it if everything is fine.

You may also consider signing the RPM package using rpmsign from the rpm-sign package and your PGP key, but this is no requirement for manual installation of RPMs.

Best regards, // Veit

[veitw]

This is how a walk through of the previous commands looks like (I truncated some output):

[build@localhost ~]$ pwd
/home/build

[build@localhost ~]$ ll
total 4
-rw-rw-r--. 1 build build 4090 Nov  5 16:18 meshcommander.spec

[build@localhost ~]$ rpmdev-setuptree

[build@localhost ~]$ ll
total 8
-rw-rw-r--. 1 build build 4090 Nov  5 16:18 meshcommander.spec
drwxrwxr-x. 7 build build 4096 Nov  5 16:25 rpmbuild

[build@localhost ~]$ tree rpmbuild/
rpmbuild/
|-- BUILD
|-- RPMS
|-- SOURCES
|-- SPECS
`-- SRPMS

5 directories, 0 files

[build@localhost ~]$ rpmlint meshcommander.spec 
0 packages and 1 specfiles checked; 0 errors, 0 warnings.

[build@localhost ~]$ spectool -f -g -R meshcommander.spec 
Getting http://info.meshcentral.com/downloads/mdtk/MeshCommander.msi to /home/build/rpmbuild/SOURCES/MeshCommander.msi
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 29.6M  100 29.6M    0     0  4704k      0  0:00:06  0:00:06 --:--:-- 5886k
Getting https://dl.nwjs.io/v0.42.2/nwjs-v0.42.2-linux-x64.tar.gz to /home/build/rpmbuild/SOURCES/nwjs-v0.42.2-linux-x64.tar.gz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 82.7M  100 82.7M    0     0  9498k      0  0:00:08  0:00:08 --:--:-- 9933k

[build@localhost ~]$ rpmbuild -bb meshcommander.spec
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.L5sxlH
+ umask 022
+ cd /home/build/rpmbuild/BUILD
+ cd /home/build/rpmbuild/BUILD
+ rm -rf meshcommander-0.7.9
+ /usr/bin/mkdir -p meshcommander-0.7.9
+ cd meshcommander-0.7.9
+ /usr/bin/gzip -dc /home/build/rpmbuild/SOURCES/nwjs-v0.42.2-linux-x64.tar.gz
+ /usr/bin/tar -xof -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .
+ mkdir msi
+ msiextract -C msi /home/build/rpmbuild/SOURCES/MeshCommander.msi
...
Provides: application() application(meshcommander.desktop) libEGL.so()(64bit) libGLESv2.so()(64bit) libffmpeg.so()(64bit) libnode.so()(64bit) libnw.so()(64bit) meshcommander = 0.7.9-1 meshcommander(x86-64) = 0.7.9-1
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Requires: ld-linux-x86-64.so.2()(64bit) ld-linux-x86-64.so.2(GLIBC_2.2.5)(64bit) ld-linux-x86-64.so.2(GLIBC_2.3)(64bit) libX11-xcb.so.1()(64bit) libX11.so.6()(64bit) libXcomposite.so.1()(64bit) libXcursor.so.1()(64bit) libXdamage.so.1()(64bit) libXext.so.6()(64bit) libXfixes.so.3()(64bit) libXi.so.6()(64bit) libXrandr.so.2()(64bit) libXrender.so.1()(64bit) libXss.so.1()(64bit) libXtst.so.6()(64bit) libasound.so.2()(64bit) libasound.so.2(ALSA_0.9)(64bit) libasound.so.2(ALSA_0.9.0rc4)(64bit) libatk-1.0.so.0()(64bit) libatomic.so.1()(64bit) libatspi.so.0()(64bit) libc.so.6()(64bit) libc.so.6(GLIBC_2.10)(64bit) libc.so.6(GLIBC_2.11)(64bit) libc.so.6(GLIBC_2.14)(64bit) libc.so.6(GLIBC_2.15)(64bit) libc.so.6(GLIBC_2.16)(64bit) libc.so.6(GLIBC_2.17)(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.3)(64bit) libc.so.6(GLIBC_2.3.2)(64bit) libc.so.6(GLIBC_2.3.3)(64bit) libc.so.6(GLIBC_2.3.4)(64bit) libc.so.6(GLIBC_2.4)(64bit) libc.so.6(GLIBC_2.6)(64bit) libc.so.6(GLIBC_2.7)(64bit) libc.so.6(GLIBC_2.9)(64bit) libcairo.so.2()(64bit) libcups.so.2()(64bit) libdbus-1.so.3()(64bit) libdl.so.2()(64bit) libdl.so.2(GLIBC_2.2.5)(64bit) libexpat.so.1()(64bit) libffmpeg.so()(64bit) libgcc_s.so.1()(64bit) libgcc_s.so.1(GCC_3.0)(64bit) libgdk-3.so.0()(64bit) libgdk_pixbuf-2.0.so.0()(64bit) libgio-2.0.so.0()(64bit) libglib-2.0.so.0()(64bit) libgobject-2.0.so.0()(64bit) libgtk-3.so.0()(64bit) libm.so.6()(64bit) libm.so.6(GLIBC_2.2.5)(64bit) libnspr4.so()(64bit) libnss3.so()(64bit) libnss3.so(NSS_3.10)(64bit) libnss3.so(NSS_3.11)(64bit) libnss3.so(NSS_3.11.1)(64bit) libnss3.so(NSS_3.12)(64bit) libnss3.so(NSS_3.12.3)(64bit) libnss3.so(NSS_3.2)(64bit) libnss3.so(NSS_3.22)(64bit) libnss3.so(NSS_3.3)(64bit) libnss3.so(NSS_3.4)(64bit) libnss3.so(NSS_3.5)(64bit) libnss3.so(NSS_3.6)(64bit) libnss3.so(NSS_3.8)(64bit) libnss3.so(NSS_3.9)(64bit) libnss3.so(NSS_3.9.2)(64bit) libnssutil3.so()(64bit) libnssutil3.so(NSSUTIL_3.12)(64bit) libnssutil3.so(NSSUTIL_3.12.3)(64bit) libnw.so()(64bit) libpango-1.0.so.0()(64bit) libpangocairo-1.0.so.0()(64bit) libpthread.so.0()(64bit) libpthread.so.0(GLIBC_2.2.5)(64bit) libpthread.so.0(GLIBC_2.3.2)(64bit) libpthread.so.0(GLIBC_2.3.3)(64bit) librt.so.1()(64bit) librt.so.1(GLIBC_2.2.5)(64bit) libsmime3.so()(64bit) libsmime3.so(NSS_3.2)(64bit) libuuid.so.1()(64bit) libuuid.so.1(UUID_1.0)(64bit) libxcb.so.1()(64bit) rtld(GNU_HASH)
Checking for unpackaged file(s): /usr/lib/rpm/check-files /home/build/rpmbuild/BUILDROOT/meshcommander-0.7.9-1.x86_64
Wrote: /home/build/rpmbuild/RPMS/x86_64/meshcommander-0.7.9-1.x86_64.rpm
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.rMWzEe
+ umask 022
+ cd /home/build/rpmbuild/BUILD
+ cd meshcommander-0.7.9
+ /usr/bin/rm -rf /home/build/rpmbuild/BUILDROOT/meshcommander-0.7.9-1.x86_64
+ exit 0

I would also upload a ready-built RPM file here, but Github rejects files >10MB.

[veitw]

PS:

The original 16x16 favicon.png looked somewhat like sh*t in GNOME when switching tasks: Because of this the specfile extracts the primary 32x32 image from favicon.ico and uses ImageMagick to apply a pixel perfect scaling to 256x256, so GNOME will not scale it blurry. This PNG is then used for both replacing the application favicon.png: ... and as application icon for the application starter:

But of cause it would be much nicer to have either a vector graphic icon as SVG or a higher resolution 256x256 PNG with alpha transparency. Is such an image available? If yes and if it was online, I will do the required changes to the specfile to include it.

[Ylianst]

Good request about the icon. I will take a look at this at some point. The icon looks bad even on Windows.

[veitw]

I created a simple website with description and downloads of

• the spec file
• the resulting RPM package
• the instructions on how to build the package

MeshCommander on Linux Inofficial Builds

[Ylianst]

Wow! That is great.

[veitw]

My inofficial MeshCommander on Linux has been updated to MeshCommander 0.8.0:

[veitw]

Hi @Ylianst,

I recreated the Icon as a vector drawing, and some alternatives.

Do you want me to create a new icon from this?

If yes, which one is your favorite? I like either the AMT one in the middle or (assuming that the speech balloon symbolises command/commander) the rightmost one.

Do you have requests for modification?

Greetings, // Veit

[Ylianst]

Looking at this... my mind just exploded. The center one looks great, but maybe we should have the same as the center one, but just the two letters "MC" in the same font or a tad larger. Is it ok if I use this icon for MeshCommander? I would be wonderful!!!

[veitw]

Of course you can use it, that is why I made it. ;) Let us just agree on the text, then I will do the fine tuning, create the image files and supply the sources.

This is with MC inside:

The font is currently Arial Black, slightly streched vertically, as I found it to match the original font quite good. I may change it to another one if wanted, but once the text is fix, I would like to convert the text into a path, so the icon does no longer depend on the fonts installed on the system (Inkscape does not embed fonts into the file).

[veitw]

This is with MC inside:

I need to say that I like the "Mesh" one much better than "MC".

[veitw]

@Ylianst: May you tell my whether you want me to use "AMT" or "MC" for the icons? Or maybe rather the "Mesh" version instead? I like that most. I need that decision to avoid double work when I start optimising for small icon sizes.

Also I need to know whether you cling to the oval's width-to-height ratio of the original icon, as I would like to make it a bit wider to make it fit the 1:1 ratio optimally, especially to maximise the size of the text in small icons -- compare the center with the right one (also: "Mesh" text scaled):

I already optimised the drop shadow and thickened the violett sharp shadow.

[Ylianst]

I love community feedback. After the input above, I am going to use "Mesh" 👍 Hold on, working on it now.

[Ylianst]

Many thanks. Just pushed a new version of MeshCommander with the new icon. I did not bump up the version number, so it's still 0.8.0. You need to uninstall, downloads, reinstall to update. Feedback welcome.

[MailYouLater]

I also like the "Mesh" version, as it can be seen as the speech bubble representing a command, and it also makes me laugh a little internally because it reminds me of the "Mush" command used in dogsled races.

[veitw]

Hi @Ylianst,

Many thanks. Just pushed a new version of MeshCommander with the new icon. I did not bump up the version number, so it's still 0.8.0. You need to uninstall, downloads, reinstall to update. Feedback welcome.

glad you like it, but I was not done yet... ;)

I will continue to create icons in different sizes for best sharpness and readability and create an .ico file from it. I will also create a standards compliant SVG scalable graphics for Unix desktops.

When I am done, I will upload both the results and the sources here, so you have them ready if other sizes or other changes are required in the future.

Regards, // Veit

[veitw]

Hi @Ylianst,

here are the finished icons: meshcommander-icons.zip

The ZIP archive contains:

• rendered/
  • meshcommander-256x256.png (256x256px 24bpp+alpha PNG, is automatically scaled in modern Windows to create for desktop icons, Explorer icon view icons, HiDPI icons, etc., equally used by older Unix/Linux desktops)
  • meshcommander-48x48.png (48x48px 24bpp+alpha PNG, used in older Windows for desktop and Explorer icon view icons)
  • meshcommander-32x32.png (32x32px 24bpp+alpha PNG, used for compact view icons, etc.)
  • meshcommander-24x24.png (24x24px 24bpp+alpha PNG, used for Explorer list/compact view, favicon, menu icons, etc.)
  • meshcommander-16x16.png (16x16px 24bpp+alpha PNG, used for Explorer list view, favicon, etc.)
  • meshcommander.ico (Windows ICO containing all the above icons; for maximum compatibility, 256x256 is compressed, all others uncompressed)
  • meshcommander-scalable.svg (font independent SVG vector graphics, used in modern Linux/Unix desktops, maybe also macOS?)
• source/
  • meshcommander-source-256x256+scalable.svg (font dependent Inkscape SVG, source for meshcommander-256x256.png and meshcommander-scalable.svg)
  • meshcommander-source-48x48.svg (font dependent Inkscape SVG, source for meshcommander-48x48.png)
  • meshcommander-source-32x32.svg (font dependent Inkscape SVG, source for meshcommander-32x32.png)
  • meshcommander-source-24x24.svg (font dependent Inkscape SVG, source for meshcommander-24x24.png)
  • meshcommander-source-16x16.svg (font dependent Inkscape SVG, source for meshcommander-16x16.png)
  • meshcommander-windows-ico.xcf (GIMP file containing all the PNGs above; conversion intermediate to create meshcommander.ico)

Both Inkscape and GIMP are also available for Windows, if you need to make modifications. The font required to use the source files is Microsoft Arial Black. The font needs to be acquired from external sources as it is not embedded in the source SVGs or contained in the ZIP archive. Also the rendered SVG do not contain the font itself but only paths created from the font's characters used.

I hereby transfer all rights to all works/files submitted in this post to the public domain for free and libre use. Contribution credits (Veit Wahlich) would be appreciated but are not required.

If you include both the meshcommander-scalable.svg and the meshcommander-*.png into the MeshCommander MSI package, I could remove the build dependency for ImageMagick from the spec file. If this is not possible, I could remove the dependency nontheless by offering the files for download on my MeshCommander on Linux Inofficial Builds website, but this would make the package creation process to be dependent on the availability of my website.

Best regards, // Veit

[veitw]

I also like the "Mesh" version, as it can be seen as the speech bubble representing a command

Exactly what I thought. :D

[MailYouLater]

I also like the "Mesh" version, as it can be seen as the speech bubble representing a command

Exactly what I thought. :D

I got that from your previous post, but it really stands out as such in my mind after having thought of the similarity to the "Mush" command. 🤣

[veitw]

Hi @Ylianst,

while trying to save my newly created setup.bin file in my MeshCommander on Linux, I stumbled upon a problem; the file was not saved, though no error message was emitted, not even on the console. I then tried to save a mescript from the script editor with the same results.

I narrowed this down to the usage of fs.writeFile() with 3 parameters, which seems to have changed between the (ancient? ;)) NW.js 0.12.3 that you bundle with the Windows version, and version 0.42.2 that I was using for my Linux 0.8.0-1 build.

At first I tried to use v0.12.3 for the Linux build, where I expected no compatibility issues, but that 2015 version does not run well on current Linux desktops, especially the font rendering is bad and has strange artefacts. The root might be the Wayland display server, that most Linux distros switched to after 2015.

I then evaluated which version of NW.js is the latest that allows fs.writeFile() to be called the way you do: The behaviour has changed from NW.js version 0.30.0 to 0.30.1; so 0.30.0 is the latest version that works with your code. It also looks good on modern Linux. Unfortunately, 0.30.0 is not backwards compatible with the NW.js profile written by 0.42.2, so data is lost for users of the builds using 0.42.2.

Because of this and as I think you may need to upgrade to a more recent NW.js in the near future anyway, before I release a new build based on NW.js 0.30.0, I would like to request to upgrade the Windows version to a recent NW.js and do the required changes:

This screenshot shows the error messages emitted to the console, the first one being the mescript save fs.writeFile(), the second one the setup.bin save fs.writeFile() call:

This is the setup.bin call of fs.writeFile() as an example:

This looks fs.writeFile(file, data, options), but according to the Node docs, it now has to be fs.writeFile(file, data[, options], callback) where the last parameter is always a callback function for error handling.

Best regards, // Veit

PS: This list is not complete, it show just the two cases that were obvious for me to click-check whether this only affects saving setup.bin. I found that all other calls of fs.writeFile() need to be updated, too.

[Ylianst]

Agreed, I need to support the new calls :) I like the older NW.js because it's smaller, but will need to update at some point. I will take a look into this.

[Ylianst]

I just did a silent update of MeshCommander v0.8.0 that fixes this. I did not change the version number to not trigger auto-update, but if you download the latest MSI or source package I added an empty function to each file write and it fixes it for both old and new NW.js. Let me know if that works for you, I just tested it on both NW.js and it worked on my side.

[veitw]

Thank you very much! I will test the changes at work tomorrow and report back.

Maybe newer NW.js releases also have increased performance, especially for AMT KVM console, so a bigger download/installation footprint might be justified by that? :)

[MailYouLater]

Maybe newer NW.js releases also have increased performance, especially for AMT KVM console, so a bigger download/installation footprint might be justified by that? :)

That's something you'd want to test, not just assume. Another thing to consider is if newer NW.js releases have changes that affect security (either positively or negatively).

[veitw]

Maybe newer NW.js releases also have increased performance, especially for AMT KVM console, so a bigger download/installation footprint might be justified by that? :)

That's something you'd want to test, not just assume. Another thing to consider is if newer NW.js releases have changes that affect security (either positively or negatively).

Of course, just a suggestion to test for. Just as I found out that performance differences can be huge (at least on Linux, Firefox Quantum's performance for the AMT console is so much better than current Chrom{e|ium}'s), I think it is worth to check whether newer NW.js might have become at least a bit faster over the past 4.5 years for a smoother UX. I am not a heavy Chrom{e|ium}/v8 user, but I assume it has received major optimisation, too.

[veitw]

Hi @Ylianst,

thank you for the API changes, this fixed the problem for both test cases.

I will prepare MeshCommander on Linux Inofficial release 0.8.0-2, including your changes from the latest Windows release and the new icons. As my version of the icons including the SVG are not part of the Windows release (yet), I will host those icons on my website and download from there. This will also remove the build dependency on ImageMagick.

Best regards, // Veit

[veitw]

MeshCommander on Linux Inofficial version 0.8.0-2 has been released.

Changes since 0.8.0-1:

• 0.8.0 silent release with fixes for Node API changes in NW.js 0.30.1 and later.
• Updated NW.js to 0.42.6.
• New icons, removing build dependency on ImageMagick.

The new icons have a nice, smooth look and integrate quite well with other applications':

[Ylianst]

Oh my! This is just wonderful!!!

[Ilia1]

@veitw Hi, the site is no longer available, where can I download packages for Linux?

[veitw]

Hi @Ilia1,

the website is still available, it was just offline for a few hours due to routing issues.

Best regards, // Veit

[veitw]

MeshCommander on Linux Inofficial version 0.8.1-1 has been released.

Changes since 0.8.0-2:

• 0.8.1 release.

[jacobopantoja]

Hi everyone, I'm not being able to get IDER working on Linux (npm version, right now on 0.8.4 but same in 0.8.3 and 0.7.9 IIRC)

I can select an ISO, it is displayed for some seconds (0 in, 18 out), and then disappears. I don't know how to debug it, neither.

BTW, I'm using Firefox on ArchLinux, so everything should be very up to date.

[veitw]

MeshCommander on Linux Inofficial version 0.8.5-1 has been released.

Changes since 0.8.1-1:

• 0.8.5 release.

[Frank-Steiner]

Veit, would you mind to provide the src.rpm on your download page, too, so that an easy and quick rebuild with "rpmbuild --rebuild meshcommander.src.rpm" is possible to make it compatible with our (older) rpmlib versions? cu, Frank

[veitw]

Hi @Frank-Steiner,

I thought about that in the beginning but then dropped that idea as *.src.rpm suggests that it is build from source code or even might be verifiable, but it is not as it uses both MeshCommander and NW binary builds. So I provided the specfile plus this guide instead,so everyone could use this to build the RPM from the externally provided binary builds. Unfortunately, the specfile always builds the current version but naming it the version specified in the specfile. This is because @Ylianst does not provide download links with identifiable version numbers.

Later this day I will provide an updated MeshCommander on Linux Inofficial version 0.8.8. I will think about providing a SRPM, too, maybe after renaming the file to .nosrc.rpm or equivalent.

Best regards, // Veit

[veitw]

MeshCommander on Linux Inofficial version 0.8.8-1 has been released.

Changes since 0.8.5-1:

• 0.8.8 release.

Upon request, this is the first release accompanied by a SRPM containing the specfile and the third-party builds used to create the RPM above).

[veitw]

@Frank-Steiner: Did this work as expected?

[Frank-Steiner]

Hi Veit, wow, that was quick :-) Thanks a lot for your support! It works almost, except that SuSE seems to have a different view of applications subcategories, so building fails when checking the desktop file: ERROR: No sufficient Category definition: /root/tmp/meshcommander-0.8.8-1.x86_64/usr/share/applications/meshcommander.desktop

"Utility" is not an accepted subcategory of "Network", but SuSE enforces every main category to be followed by a subcategory (while freedesktop.org only proposes that), while Network and Utility are both main categories. Unfortunately, this check can't be disabled, and SuSE also doesn't provide any matching subcategories for Utility that would help here, so I can't propose a valid change to the desktop file. So, I will still have to patch the spec file :-( Anyway, it's way easier to to that with a little script with the nosrc.rpm, so this is very helpful despite this little SuSE-specific problem.

Thanks a lot!

[veitw]

Hi @Frank-Steiner,

I could change the Categories line to Categories=Network;RemoteAccess; as Network/RemoteAccess seems to exist in both SuSE and RedHat based distros and matches MeshCommander's use case quite well.

Alternatively I could add a distro switch to the specfile, employing the %suse_version macro to identify the distro and use an alternative .desktop file in this case. But I think keeping a uniform specfile without distro switches is the better solution.

Can you verify that "Categories=Network;RemoteAccess;" would do the trick for SuSE?

Best regards, // Veit

[Frank-Steiner]

Yes, that works fine! Thanks for caring, I really appreciate that!

[veitw]

MeshCommander on Linux Inofficial version 0.8.8-2 has been released.

Changes since 0.8.8-1:

• Updated FDO categories to enable building on SuSE based distros.

SRPM containing the specfile and the third-party builds used to create the RPM above.

[veitw]

@Frank-Steiner: The SRPM has been updated, see release link above. Please try running rpmbuild --rebuild on it and report back the result.

[Frank-Steiner]

Works great! Many thanks :)

[veitw]

MeshCommander on Linux Inofficial version 0.9.0-1 has been released.

Changes since 0.8.8-2:

• 0.9.0 release.

SRPM containing the specfile and the third-party builds used to create the RPM above.