-
Notifications
You must be signed in to change notification settings - Fork 18
Added support for AIX platform (for issue #5) #9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
The script aix.js is compatible with AIX on PPC64 architecture. If some time in future AIX on another architecture should be supported, then add separate code paths, depending on the architecture.
I'm really worried about adding a C++ dependency, even if optional because if I remember correctly package installation can under some circumstances fail if a optional dependency fails to build. I assume you looked around if there is a pure JS alternative? Can we be sure that a build it not attempted if platform is not AIX? |
aix.js
Outdated
|
||
const getSqlStatement = family => { | ||
let sql = | ||
"select NEXT_HOP from QSYS2.NETSTAT_ROUTE_INFO where ROUTE_TYPE='DFTROUTE'"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this table possibly also contain the name of the network interface of the default gateway? If so, we can fill the interface
property of the result with it, if its present.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
According to this it might be LOCAL_BINDING_INTERFACE
but it says it will be null for IPv6, so not sure if worth to add if it only works for IPv4.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I‘m gonna have a look on it tomorrow. If it‘s null, I‘m gonna make sure it‘s at least an empty string, using coalesce, or maybe there‘s some other way round.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah result should be non-empty string or null. Guess it does have some value to have it at least in the IPv4 case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I checked the LOCAL_BINDING_INTERFACE
, and it contains, indeed, the interface address. So I added it.
aix.js
Outdated
|
||
if (results && results[0] && results[0].NEXT_HOP) { | ||
resolve({ | ||
gateway: results[0].NEXT_HOP |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Documentation says that the special value *DIRECT
for NEXT_HOP
is "the next hop value of a route that is automatically created.".
Maybe this special value should be handled similar to the Linux case of default via dev
? I realize that returning the matching interface address is not totally correct (practically, there is no default gateway address an route via interface), but it's better than failing, I suppose.
Alternatively, we could just fail if *DIRECT
is encountered.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as I‘ve seen in the database, there is an entry with value *DIRECT
, that‘s why I filter on ROUTE_TYPE=‘DFTROUTE‘
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe add NEXT_HOP!='*DIRECT'
to the query as a safeguard, if it is necessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added the NEXT_HOP
filter
I tried everything me and my boss could come up with to gather the information using vanilla js, but no other approach worked :/ I understand your worries. Would it be possible to manage this situation with a pre-install script that only installs idb-connector if it‘s aix on ppc64? I have no such experience, but I read somewhere there‘s an event hook for this... |
It may actually be fine. The package specifies |
aix.js
Outdated
|
||
const getGatewayInformationAsync = async family => { | ||
return new Promise((resolve, reject) => { | ||
const idbConnector = require("idb-connector"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You should try ... catch
these require
statements and return the "Unable to determine default gateway"
error on catch. Normally I'd say to let the error through to the consumer, but the module has been consistent in returning only this specific error.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wrapped the connector functions as well
Changed sql statement to only return entries where NEXT_HOP!=*DIRECT Changed sql statement to return LOCAL_BINDING_INTERFACE as well Changed return values to contain "interface" as well (fallback: empty string) Wrapped all require's and database functions to throw especially "Unable to determine..." in error case
In terms of the optional dependency on |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good. Is this latest version properly tested? Does it work for unpriviledged users?
Not sure what you mean. We only have local dependencies (in node_modules), what could be the issue?
It's fine as it is. |
I tested it on our aix (as/400) system and on my windows machine. Didn‘t cause problems as far as I was able to test it. I assumed the Travis CI takes care of the other systems (Linux etc) as I have no Linux machine available. |
if (results && results[0] && results[0].NEXT_HOP) { | ||
resolve({ | ||
gateway: results[0].NEXT_HOP, | ||
interface: results[0].LOCAL_BINDING_INTERFACE || "" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does the query return a actual null
for LOCAL_BINDING_INTERFACE
in the IPv6 case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since it‘s a system table, it might be null. That‘s why I put it like this, just in case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, but I want to know if the null
in the docs transform to a actual JavaScript null
value or maybe 'null'
or other weird things.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, this is what you mean.
According to the source of idb-connector dbstmt.cc ist translates SQL_NULL_DATA
to an actual null
value
See dbstmt.cc lines 344-345
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for digging that out!
Travis isn't actually in use (e.g. tests are skipped) because last I checked, their VMs did not have network interfaces, but that may have changed recently. |
Okay, so we need to run separate tests on other systems manually as well? There changes shouldn‘t interfer with the previous code at all, since I put it into a separate file... but ofc, a package used that much needs to be tested properly. |
No need to run tests elsewhere, the change can possibly only affect AIX. I will look into enabling tests on travis again later. |
Is there anything left to do for me? |
I merged it to master now, with additional tweaks in f7903f5. Can you please test current master on your machine? |
Tested -> works as expected |
The script aix.js is compatible with AIX on PPC64 architecture. If some time in future AIX on another architecture should be supported, then add separate code paths, depending on the architecture.
Solves issue #5