codeforiserver-1.4 are not found for Users

[santoshkatagi]

Developers in our Organization are connected to VS Code. Few of them do not have this codeforiserver-1.4 Jar file in there IFS Path.

For Auditing, how do we capture the users accessing through VS Code to IBMi?

[sebjulliand]

This jar file used to be the Db2 for i extension server component, but not anymore. It's been replaced by mapepire-server-x.y.z.jar. So that's normal. Besides, these files are put in the temporary folder defined in the connection settings - this folder can be cleared without causing any damage.

As for capturing users accessing IBM i from VS Code, that should be done by auditing the SSH connections, since Code for IBM i uses SSH to connect to the LPAR.

[worksofliam]

Additionally, the database extension uses standard JDBC to communicate with the database.

[santoshkatagi]

@sebjulliand @worksofliam We audited the syslog for SSHD in VERBOSE mode. However, we are unable to distinguish the traffic generated by Visual Studio Code (VS Code) from regular SSH traffic. Any alternative solutions or suggestions to address this issue would be greatly appreciated.

[buzzia2001]

Hi @santoshkatagi,
from a system point of view, ssh lacks some features that are unique to other TCP servers on IBM i environments. For example exit programs...
So, you have enabled SYSLOG service on IBM i, you can also check entries from QAUDJRN (JS entries for start job, PS for change profile) but as I said before ssh as a strange behaviour, for example every command is managed by a different job and so on...
So I don't think that is possible to separate traffic, an easy way is to use dedicated users but I don't know if it's a fine way for your auditors

[MarcoDeSenas]

On my installation, each time I connect from Code4i, there is a database job initiated from the ssh session with my user profile, through running a mapepire jar file. It is initiated using the local 127.0.0.1 interface so not using SSL. This is a QZDASOINIT job. Therefore, you may try to enable an exit point on database accesses (checkout https://www.ibm.com/docs/en/i/7.5.0?topic=performance-exit-programs) which scans the joblog to find the SQL799C message as below.

I never tried this and I don't really know to which point in job flow, this exit point applies in regard to SQL799C.
You can review Output/Db2 for i Server Component to see the database job invoke.
And you hit "View job log" option when hoverring the new job button at the bottom.

Maybe be it will fullfill your need!

[MarcoDeSenas]

Maybe easier than scanning the joblog: information about the client application might already exist in ZDAI0100 format used by QIBM_ZDA_INIT exit point.
https://www.ibm.com/docs/en/i/7.6.0?topic=eppf-parameter-fields-exit-point-qibm-qzda-init-format-zdai0100
Just run a test to see how it looks like.
Then, if you need robust audit purposes, you can add a user entry (SNDJRNE command) to a specific journal (it is recommended by IBM not to use QAUDJRN journal https://www.ibm.com/docs/en/i/7.6.0?topic=journal-managing-audit-receivers), as journal entries cannot be removed.

[buzzia2001]

Hi,
remember that is not always true that we you connect you start a sql job, it depends on the user configuration

[sebjulliand]

The database job is started by the DB2 extension. Code for IBM i itself uses exclusively SSH.

[MarcoDeSenas]

OK, so an exit point on database access is not a proper solution for all contexts. Bad luck :-)

[sebjulliand]

Yep, but that would have been great otherwise 😄

@santoshkatagi I guess there would be nothing special in the way Code for i connects that could help you differentiate its connections from others.

The only it does that is very specific to run this command before doing anything else: echo "This should be the only text!"
So if you're able to detect SSH connections running this command, you'd be able to tell it's a Code for i connection.