istoredp.js error

[abmusse]

Original report by Robert Brown (Bitbucket: rbpaservices, GitHub: rbpaservices).

---

I am having an issue using a node.js websockets tutorial http://www.ibm.com/developerworks/ibmi/library/i-running-websocket-applications-on-ibmi-trs/index.html This displays a webpage and creates a websockets connection on the IBMi. After the connection, I enter a command WRKSYSSTS and it returns the information to the web page display. This works perfectly fine when I am in my normal IBMi user. The same code does not work in a chroot environment. It displays the screen and connects correctly, but when I enter the command and error is logged to the console and nothing is displayed. I have tried this with 2 different chroot enviroments(and users) and I have tried using NODE, NODE4, and NODE6. the error is bash-4.3$ . ~/node6_env.sh -bash-4.3$ echo {$PATH} {/QOpenSys/QIBM/ProdData/OPS/Node6/bin:/QOpenSys/usr/bin:/usr/ccs/bin:/QOpenSys/usr/bin/X11:/usr/sbin:.:/usr/bin} -bash-4.3$ node --version v6.9.1 -bash-4.3$ node index.js Wed Jan 18 2017 14:34:16 GMT+0000 (EST) HTTP Server is listening on port 8888 Wed Jan 18 2017 14:34:16 GMT+0000 (EST) HTTPS Server is listening on port 8889 Wed Jan 18 2017 14:34:33 GMT+0000 (EST) Received request for /WSConsole.html Wed Jan 18 2017 14:34:46 GMT+0000 (EST) Received request for /CLRunner. Wed Jan 18 2017 14:34:46 GMT+0000 (EST) Peer ::ffff:24.115.110.36 connected. Wed Jan 18 2017 14:35:22 GMT+0000 (EST) Received Message: WRKSYSSTS Cannot convert between code set (CCSID 1208) and code set (CCSID 37) Cannot convert between code set (CCSID 819) and code set (CCSID 37) TypeError: db.dbconn is not a constructor at Object.db2Call (/QOpenSys/QIBM/ProdData/OPS/Node6/os400/xstoolkit/lib/istoredp.js:90:18) at iConn.run (/QOpenSys/QIBM/ProdData/OPS/Node6/os400/xstoolkit/lib/itoolkit.js:265:10) at WebSocketConnection. (/home/NODEUSR1/wsexample/index.js:52:12) at emitOne (events.js:96:13) at WebSocketConnection.emit (events.js:188:7) at WebSocketConnection.processFrame (/home/NODEUSR1/wsexample/node_modules/websocket/lib/WebSocketConnection.js:547:26) at /home/NODEUSR1/wsexample/node_modules/websocket/lib/WebSocketConnection.js:321:40 at _combinedTickCallback (internal/process/next_tick.js:67:7) at process._tickCallback (internal/process/next_tick.js:98:9) I think the main error is the TypeError: db.dbconn is not a constructor. The system value, user value and job value are CCSID 37. Once again, this does work fine, no changes, outside the chroot.

[abmusse]

Original comment by Aaron Bartell (Bitbucket: aaronbartell, GitHub: aaronbartell).

---

Further to what @rangercairns said, it is for that reason, at least in part, that the db2util tool was created; so you can run CL commands through XMLSERVICE from a PASE shell without requiring a scripting language's iToolkit.

Also, you're doing great on the learner part. What "seals the deal" is when you take your knowledge and teach others in the IBM i community. That's the expectation Tony has when he teaches me things and I do my best to take the things I learn and teach others.

I am inspired that you've dug in this deep. Others would have stopped at the error and not cracked opened the iToolkit code. Keep it up!

[abmusse]

Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).

---

Fair idea. No (i think.) Unfortunately, when run 'system' in a chroot you simply do not get any output. So, tools like language toolkits are only returning exactly what comes out of PASE 'system' command, aka, nothing (below). It would be difficult for generic service like toolkits to 'know' output of a system command equal nothing 'is not normal'. That is, perhaps functions names something like 5250thing could check to see if /QSYS.LIB is visible, but using raw 'system wrksyssts' and hundreds of other OS commands would be impossible to predict as 'wrong' (yikes).

#!shell

bash-4.3$ system wrksyssts   
bash-4.3$ 

[abmusse]

Original comment by Robert Brown (Bitbucket: rbpaservices, GitHub: rbpaservices).

---

One suggestion.  If it’s possible to detect the chroot environment where it is not intended to work, maybe a specific an error message like “chroot not supported”  or  “cannot access QSYS” or something more descriptive than what is currently produced.

Thanks for the teaching , hope I was doing my learning part

Bob Brown

[abmusse]

Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).

---

I believe we worked through the various 'teaching elements' about chroot with this issue. I am closing.

[abmusse]

Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).

---

Ah, very good. Beautiful northern Minnesota. Less Wi-Fi. More fish. Mostly, no tweets (old guys).

[abmusse]

Original comment by Robert Brown (Bitbucket: rbpaservices, GitHub: rbpaservices).

---

I spent a lot of time in northern Minnesota, married near Duluth.

[abmusse]

Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).

---

Mmm ... not to overstate ... and speculation (of course) ... but ... don't forget to add chroot_setup.sh chroot_nls.lst into your chroot. Again iToolKit is a XML based thing, aka, string thing, therefore if convert fails XML parsing in the toolkit ... well ... command may appear to fail to human eye (no parse XML due to conversion).

[abmusse]

Original comment by Aaron Bartell (Bitbucket: aaronbartell, GitHub: aaronbartell).

---

Concerning running WRKSYSSTS and the system command; I am assuming you're already using the Node.js iToolkit given the nature of the error (i.e. istoredp.js is connecting to the database and not attempting to run system in your current/chroot PASE session).

But, again, I am assuming. Can you put together a small example that conveys the error and post it here?

[abmusse]

Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).

---

Correct. In every case, i am always trying to 'help' with the heart of a teacher. However my north Minnesota Norwegian heritage coupled with unfortunate family singular wit, may, at times, result in 'minnesotan' narrative.

[abmusse]

Original comment by Robert Brown (Bitbucket: rbpaservices, GitHub: rbpaservices).

---

Thanks

[abmusse]

Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).

---

Cannot convert between code set (CCSID 1208) and code set (CCSID 37)

When you see a message like this 'cannot convert', you forgot to copy NLS (3).

#!shell

> chroot_steup.sh  chroot_nls.lst /QOpenSys/mychroot

(3) PASE is not like ILE. That is, PASE requires NLS files copied into the chroot manually (chroot_nls.lst). ILE on the other hand, all conversion 'tables' are shipped inside the kernel, therefore no mess, no fuss.

BTW -- not all PASE nls conversion 'tables' are installed with Option 33 (PASE). You must install individual secondary languages for PASE to see the full set of PASE 'tables' (i feel your pain -- EOM).

[abmusse]

Original comment by Robert Brown (Bitbucket: rbpaservices, GitHub: rbpaservices).

---

I am not really interested in the Java version of the tutorial, I only mentioned it because it is part of the tutorial. I used the Node section only. If I understand you correctly, running the commands directly from chroot is not supported so, there is no real issue here. It's only a lesson for me, maybe I can learn more about the other things you are talking about and make it work.

[abmusse]

Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).

---

Two cents ...

The Java factor ... We do not know if Java can be successfully copied into a chroot and 'run' (2). We do not have a chroot_java.lst to even attempt the task (any volunteer welcome). Speculation ... the 'pase side' of java will run fine ... the ILE side of Java should work because the pase system calls (_ILELOAD, _ILESYM, _PGMCALL, etc.), all use the lib/file.mbr version of ILE program resolution (aka, successfully hack chroot missing /QSYS.LIB). So again, any volunteer is welcome to explore building a chroot_java.lst.

The WRKSYSSTS factor ... Most any script language will take the short route to using the pase utility system wrksysstst. Unfortunately pase utility system will not work in a chroot, because chroot has lost ability to see /QSYS.LIB (intentional - works as designed). To make a long story short, to execute 'wrksyssts' you probably need to use language toolkits based on XMLSERVICE. More precisely, you must use a toolkit 'transport' like DB2 (xmlservice stored proc API), or, 'transport' REST (xmlservice xmlcgi Apache set-up). The reason toolkit-2-xmlservice DB2 or REST will work is because these 'daemons' are started outside the chroot by the administrator (aka, strtcpsvr *http, strsbs qsqsrvr). To wit, we can break the chroot by using the toolkit inside and calling out to jobs started by admin outside chroot (1).

(1) FYI -- no chroot security issue with toolkit to DB2 or REST, simply the way the world works every platform calling jobs via 'transport' outside the chroot (Linux, etc.). However, you may not use a memory-2-memory 'transport' like python iLibCall, because we are still inside the chroot (rules apply, no /QSYS.LIB).

(2) FYI -- chroot mystery solved ... any chroot_thing.lst ... simply copying an image of IFS directory with pase programs, dependencies (pas runtime like libc.a, etc), and more, into a sub-directory. The chroot occurring on the ssh 'connect' changes the location of '/' to the sub-directory, and, will not allow the user to 'back-up' into lower directories, aka, we lost access to /QSYS.LIB ... and ... pase utility system wrksystst will no longer work in the chroot.

[abmusse]

Original comment by Robert Brown (Bitbucket: rbpaservices, GitHub: rbpaservices).

---

Not really interested in the Java, just mentioned that it was part of the tutorial and I didn't want it to be a distraction

[abmusse]

Original comment by Aaron Bartell (Bitbucket: aaronbartell, GitHub: aaronbartell).

---

Excellent job on the markdown. Much easier to read.

First, Java doesn't work in chroot. Wanted to let you know that in advance so you didn't waste time.

Second, we need to see your Node.js code. If you don't want to post your entire program then make a test case with just the offending code that causes the error.

[abmusse]

Original comment by Robert Brown (Bitbucket: rbpaservices, GitHub: rbpaservices).

---

I am having an issue using a node.js websockets tutorial WebSockets on i This tutorial has two parts, Java and Node. I am only concerned with the Node portion at this time. The issue is that the tutorial code works when I run it under a normal user ID, but the same code fails under a chroot user id.

Non CHROOT

1. Log in SSH Secure Shell with a regular user
2. Add the Node environment to the $PATH
3. Navigate to the project folder
4. enter the command node index.js

   Welcome to Secure Shell version 0.8.34.4.
   Answers to Frequently Asked Questions: https://goo.gl/muppJj
   Connecting to userid@ip.address...
   Loading NaCl plugin... done.
   userid@ip.address's password: 
   -bash-4.3$ . ~/node6_env.sh
   -bash-4.3$ echo {$PATH}
   {/QOpenSys/QIBM/ProdData/OPS/Node6/bin:/QOpenSys/usr/bin:/usr/ccs/bin:/QOpenSys/usr/bin/X11:/usr/sbin:.:/usr/bin}
   -bash-4.3$ cd wsexample
   -bash-4.3$ node index.js
   Fri Jan 20 2017 16:11:47 GMT+0000 (EST) HTTP Server is listening on port 8888
   Fri Jan 20 2017 16:11:47 GMT+0000 (EST) HTTPS Server is listening on port 8889
   Fri Jan 20 2017 16:12:06 GMT+0000 (EST) Received request for /WSConsole.html
   Fri Jan 20 2017 16:12:17 GMT+0000 (EST) Received request for /CLRunner.
   Fri Jan 20 2017 16:12:17 GMT+0000 (EST) Peer ::ffff:24.115.110.36 connected.
   Fri Jan 20 2017 16:12:30 GMT+0000 (EST) Received Message: WRKSYSSTS

   

In Chroot

1. Log in SSH Secure Shell with a chroot user
2. Add the Node environment to the $PATH
3. Navigate to the project folder
4. enter the command node index.js the initial screen and web sockets connection are made and the error gets displayed in the node console

   Welcome to Secure Shell version 0.8.34.4.
   Answers to Frequently Asked Questions: https://goo.gl/muppJj
   Connecting to chrootuserid@ip.address...
   Loading NaCl plugin... done.
   chrootuserid@ip.address's password: 
   -bash-4.3$ . ~/node6_env.sh
   -bash-4.3$ echo {$PATH}
   {/QOpenSys/QIBM/ProdData/OPS/Node6/bin:/QOpenSys/usr/bin:/usr/ccs/bin:/QOpenSys/usr/bin/X11:/usr/sbin:.:/usr/bin}
   -bash-4.3$ cd wsexample_Node
   -bash-4.3$ node index.js
   Fri Jan 20 2017 16:18:42 GMT+0000 (EST) HTTP Server is listening on port 8888
   Fri Jan 20 2017 16:18:42 GMT+0000 (EST) HTTPS Server is listening on port 8889
   Fri Jan 20 2017 16:18:58 GMT+0000 (EST) Received request for /WSConsole.html
   Fri Jan 20 2017 16:19:07 GMT+0000 (EST) Received request for /CLRunner.
   Fri Jan 20 2017 16:19:07 GMT+0000 (EST) Peer ::ffff:24.115.110.36 connected.
   Fri Jan 20 2017 16:19:25 GMT+0000 (EST) Received Message: WRKSYSSTS
   Cannot convert between code set  (CCSID 1208) and code set  (CCSID 37)
   Cannot convert between code set  (CCSID 819) and code set  (CCSID 37)
   **TypeError: db.dbconn is not a constructor**
   at Object.db2Call (/QOpenSys/QIBM/ProdData/OPS/Node6/os400/xstoolkit/lib/istoredp.js:95:18)
   at iConn.run (/QOpenSys/QIBM/ProdData/OPS/Node6/os400/xstoolkit/lib/itoolkit.js:265:10)
   at WebSocketConnection.<anonymous> (/home/nodews/wsexample_Node/index.js:51:12)
   at emitOne (events.js:96:13)
   at WebSocketConnection.emit (events.js:188:7)
   at WebSocketConnection.processFrame (/home/nodews/wsexample_Node/node_modules/websocket/lib/WebSocketConnection.js:547:26)
   at /home/nodews/wsexample_Node/node_modules/websocket/lib/WebSocketConnection.js:321:40
   at _combinedTickCallback (internal/process/next_tick.js:67:7)
   at process._tickCallback (internal/process/next_tick.js:98:9)

   

Note: The system, user, and job all have CCSID set to 37.( I believe the conversion errors displayed are a result of the error listed in the TypeError)

[abmusse]

Original comment by Aaron Bartell (Bitbucket: aaronbartell, GitHub: aaronbartell).

---

Hi Robert,

Really the only thing you need to do for your previous post is add triple accents before and after the shell sessions. It will look like this:

$ my command

It's basically like using the <pre> HTML tag to retain formatting.

[abmusse]

Original comment by Robert Brown (Bitbucket: rbpaservices, GitHub: rbpaservices).

---

I knew the markdown would make it more readable, but that is something I still need to learn and it was too late to start last night. I will give it a shot today. I have the steps I used to create the chroot documented, so it will be easy to add that. The Link to the tutorial is in the previous post and there are links to download the code. I can zip the folder and attach it here if that is allowed. BTW, Kevin Turner has posted a similar error in Ryver ibmioss/Nodejs (What is "istoredp" for in the node.js os/400 toolkit?) but I am not sure of his environment setup.

[abmusse]

Original comment by Aaron Bartell (Bitbucket: aaronbartell, GitHub: aaronbartell).

---

Hi Robert,

Could you edit the original post and use markdown to format it? Currently it is difficult to decipher :-)

What We Need

• Understand how you went about creating your chroot (i.e. which commands did you run). This will help us either recreate the issue or point out what steps need to be modified.
• The code you're attempting to run.