Windows Server 2012 Problem (AGAIN)

JasperNL

@Jenkler Docker and Windows is a hell. Docker runs on top of a virtualbox which virtualizes the linux kernel, which allows docker containerization. The result of this is that the efficiency is totally lost. Docker on windows works fine for development, but forget about using it in production

I use linux (Debian Jessie) in production and windows (windows 10, "education") for development. Both work fine. I run Mongo and NodeBB on the same VPS, and for the windows development I use mongolab (or whatever it's called now).

@Master-Antonio You may have noticed Windows is icky when it comes to compiling basically anything that is unrelated to Microsoft in any way. Therefore compiling native addons with NodeJS is a hell on Windows. For me it does only work with commandprompt cmd.exe and not with powershell or mingw. I've followed the directions here (search for the "On Windows" bullet, below installing) with option 2. For Visual C++ Build Environment I used the first option.

If you like I can send you a 64-bit precompiled node_modules tarball (rar, zip, whatever) that you can use for your deployment on the windows server. I'm quite certain that will fix this specific problem. However, that'd be no durable solution, of course

PitaJ

@JasperNL you can now use bash in a Linux environment rubbing directly on top of the windows kernel. Look up "bash on Windows"

JasperNL

@PitaJ I've read about it at LowEndTalk before, but I don't see the benefit of it over MinGW. MinGW provides most standard linux commands (ls, cd, touch, grep, ssh, scp, tar, ip) that I'll often use and what I'm used to. If I need something more advanced than that, I'll probably be better off with starting a debian VM in virtualbox
I don't have problems with using windows' commandprompt for doing things with node.js or python when MinGW starts bitching about compiling binaries for windows again. That's what I'm used to, after all..

Scuzz

Looks like

npm ERR! argv "C:\\Program Files (x86)\\nodejs\\\\node.exe" "C:\\Program Files (x86)\\nodejs\\node_modules\\npm\\bin\\np
m-cli.js" "install"

is your issue. I had the same thing a while ago when installing NodeBB on Windows. Too many backslashes for the directories.

Mikael Jenkler

@JasperNL Docker in CoreOS works extremely well. I guess you lose som performance but the upside of Docker is worth it

JasperNL

@Jenkler said in Windows Server 2012 Problem (AGAIN):

@JasperNL Docker in CoreOS works extremely well. I guess you lose som performance but the upside of Docker is worth it

Oh, I did not get that you were proposing a move to CoreOS as a whole! I thought you proposed using Docker on a Windows host. The latter is certainly a no-go, because that requires virtualbox, which is killing for the applications efficiency.

I don't know if moving to CoreOS (or a standard setup with any other linux distro) is an option that OP considers, because there may be tonnes of reasons to stay with windows. Think about IIS or Active Directory-related services, or any other thing that are itchy combined with Linux.
That's why I think providing windows-centered recommendations may be better suitable for him. I'm sure there must be a such a solution to his problem, because NodeBB could run perfectly on Windows.

@Scuzz said in Windows Server 2012 Problem (AGAIN):

Looks like
npm ERR! argv "C:\\Program Files (x86)\\nodejs\\\\node.exe" "C:\\Program Files (x86)\\nodejs\\node_modules\\npm\\bin\\np
m-cli.js" "install"
is your issue. I had the same thing a while ago when installing NodeBB on Windows. Too many backslashes for the directories.

I don't think that's the issue. Windows uses backslashes for directory pathing. The backslashes must occur twice, because otherwise it will be parsed as a single backslash (as posix-standard expressions are used as in javascript and bash).
Besides that, the error that comes up is an error from npm, which shows that npm can be executed.

The problem is described here:

npm ERR! code ECONNRESET
npm ERR! errno ECONNRESET
npm ERR! syscall read

ECONNRESET means that the connection to the packages is reset . This is most likely due to a firewall issue. Possible resolutions to that problem are turning off the firewall, or run the command prompt (or do you use powershell?) as administrator.

PitaJ

@JasperNL I think he's referring to the four backslashes in a row.

Master-Antonio

@JasperNL

I used git shell to install all.
With 1.1.0 work seems work.
https://community.nodebb.org/topic/9421/nodebb-dont-work/17

JasperNL

@Master-Antonio asked me to help him over teamviewer. I've made a fresh installation of 1.1.2, and there is a problem with links to images.

The installation worked fine, but there were problems with profile cover pictures.

The host system is a windows machine. I'm able to reproduce the bug on my local build.

This is what the inspection window looks like on my updated version from 1.1.0 to 1.1.2. I did not change my cover picture since the update.

It should be noted that the background-image field now uses normal slashes.

After changing the cover picture, the background-image field changes. to backslashes.

As of then, the cover picture stays white, because the browser cannot resolve the location.

This is clearly a bug related to 1.1.2.

JasperNL

Here's another error that he showed me.

After changing the website's logo at the ACP at settings - general, and setting the website name and browser title, the following error comes up when he goes to that page:

Error: Failed to lookup view "500" in views directory "C:\Programs\NodeBB\public\templates"
   at EventEmitter.render (C:\Programs\NodeBB\node_modules\express\lib\application.js:579:17)
   at ServerResponse.render (C:\Programs\NodeBB\node_modules\express\lib\response.js:960:7)
   at C:\Programs\NodeBB\src\middleware\render.js:63:12
   at fireFilterHook (C:\Programs\NodeBB\src\plugins\hooks.js:101:11)
   at Object.Plugins.fireHook (C:\Programs\NodeBB\src\plugins\hooks.js:85:5)
   at ServerResponse.res.render (C:\Programs\NodeBB\src\middleware\render.js:31:12)
   at C:\Programs\NodeBB\src\controllers\index.js:457:8
   at C:\Programs\NodeBB\src\middleware\header.js:44:6
   at C:\Programs\NodeBB\public\src\modules\translator.js:148:5
   at C:\Programs\NodeBB\public\src\modules\translator.js:173:6
   at C:\Programs\NodeBB\public\src\modules\translator.js:194:4
   at Object.translator.load (C:\Programs\NodeBB\public\src\modules\translator.js:225:5)
   at translateKey (C:\Programs\NodeBB\public\src\modules\translator.js:192:14)
   at C:\Programs\NodeBB\public\src\modules\translator.js:170:4
   at Array.forEach (native)
   at translateKeys (C:\Programs\NodeBB\public\src\modules\translator.js:169:8)

I'll try to reproduce the bug on my local build later. I think this is related to the issue above.

I think these problems are related to each other. Maybe that I'll open a seperate topic about this where I describe my findings in more detail. For now I'll be waiting for an answer from the developers.

@PitaJ

Master-Antonio

@julian @psychobunny

JasperNL

I think it's related to this change: https://github.com/NodeBB/NodeBB/commit/aac0313f2eb87123347c5925a134adcd57fb869e

In here the universally slashes are replaced by OS defaults which seems to cause the windows related errors. I'll check out later if there is no similar open issue and otherwise I'll open one.

julian

@JasperNL Are you sure this is the commit? Does it work fine if you use the commit before it?

JasperNL

@julian said in Windows Server 2012 Problem (AGAIN):

@JasperNL Are you sure this is the commit? Does it work fine if you use the commit before it?

I'm not completely sure. The only observation that I made is that it worked fine with v1.1.0 and not with v1.1.2, and that it has to do with file path names. (Presumably tomorrow or in 2 days) I will take a look at the version before and after this commit and test if it's causing the bug then.

I'll post my results as soon as they are there!

julian

@JasperNL In that case, I would recommend you use git-bisect as it will help you determine which commit specifically caused the regression.

JasperNL

Thanks I thought using git checkout -b (commit code) would do the job too on a clone. I'll take a look at the command you propose

JasperNL

Oh bisect looks extremely useful indeed!

JasperNL

Testing procedure

nodebb stop
Checkout the eventually wrong commit

npm install
nodebb setup
nodebb upgrade
nodebb start

Refresh page.
Remove profile cover picture
Add profile cover picture
If it remains white (and thus backslashes in background-image at the inspection view): Error; Otherwise: no error.

Testing results

commit aac0313f2eb87123347c5925a134adcd57fb869e has the bug described above.
commit 22e73b925f16d5eb9d223121291ae437ba427faf has the error too! (Edit: no it has not)
commit ff4fd8cf9523e09a5957f0b55c15d5980d02aa7d works fine.
commit 84025fa7fc17807c8d9d00b0b298611a86a8101b works fine. (roughly 2 steps left according to git bisect)
commit c00905035e5f8049881622f337b8741c7cd6c228 works fine.
commit b0c55c86ed994edbf2270d3a539af460ad871e7c works fine. This confuses me. The translator bot apparantly destroyed it? That makes no sense at all. I'll try the version of the translate bot again...
commit 22e73b925f16d5eb9d223121291ae437ba427faf has no error (I probably didn't do nodebb stop before updating, or it's something stupid like this :|)

Conclusion

22e73b925f16d5eb9d223121291ae437ba427faf Is ok;
aac0313f2eb87123347c5925a134adcd57fb869e Is not ok;

I hope this helps Please leave me a message when you need additional information.

julian

@JasperNL Well, looks like you were right all along

JasperNL

You can never be sure I hope it gets fixed soon to ensure future windows compatability