hi,
i’m on ubuntu 16.04, with 18.04 I can edit the /etc/networks/intefaces file to add something like
auto enp0s8
iface enp0s8 inet static
address 192.168.56.1
netmask 255.255.255.0
to map 192.168,.56.1 as inet address so that I can reference services on this box via this address and ifconfig command would reflect that as well, but for ubuntu 16.04 it’s not working this way. do i need to edit another network config file? i dont remember, thanks.
Typos aside, that’s the correct way to do interfaces in 16.04 as well. ( and really any debian derived os)
What does “not working” mean?
yeah, silly typo for “interfaces”,
not working, as mentioned, ifconfig command did not reflect the changes/editing of the “interfaces” file.
and yes, I did network reload and then even reboot, still in vein.
So, I did a bit more research, which suggests adding a line of the tcp address mapping to localhost at the end of the /etc/hosts, upon reboot the tcp address is then accessible.
but now I have new trouble, cfhttp call failed to connect to a REST ap server running node.js, so,
i’m using cfexecute, the trouble is each cfexecute call take excessive long to process, like 50 seconds or more. the lucee server docker image i’m using is lucee4 ( it has more votes over lucee5.2 ). need to figure out where the bottleneck is…
the components and process flow works like this:
“new tech” → which can be called via shell scripts or other methods
(when called from shell script, it’s not too slow)
"nodejs-based rest api server
lucee server (v4.5)
cf scripts/files calling the rest api server
thanks for the note.
OK, sooo what you’re saying isn’t quite right. /etc/network/interfaces doesn’t define a way to “reference services on this box via this address”. Nor does the hosts file do anything with TCP.
/etc/network/interfaces and the related files in /etc/network/interfaces.d tells Ubuntu how to configure the interfaces in the VM or Physical machine for network communication. It defines IP configuration. (Layer 3)
Your interfaces file, for instance, does not include a default gateway. So if it’s actually being used to setup a server, it won’t be able to communicate outside that subnet, nor will anything else off that subnet be able to communicate with it. No software updates. No NTP. No DNS. No anything.
The HOSTS file doesn’t do anything with layer 3 either, nor does it define IP addresses the box responds to. All it does is associate names (like localhost) with an IP address for NAME resolution.
And if you’re trying to change a docker container’s IP address, the docker container never calls ifup, or the system init scripts, nor does it have an interface named enp0s8. You’d define that in the docker networking setup, either as part of the command line, docker compose, etc.
Without more specifics as to what you’re trying to accomplish you’re not going to get a good response. (As evident from the last couple days)
Is your nodejs API on the SAME server/container as your coldfusion code? If so, who cares what the networking is. Use 127.0.0.1 and move on.
Are they both containers? Both servers? On the same subnet? Different subnet?
What “doesn’t work” with cfhttp? What “doesn’t work” with cfexecute? Did you get an error from either? Care to share?
Personally, if we’re talking about a REST API, I would NEVER consider using cfexecute as an alternative. Java and CF support HTTP natively, why introduce the complexity? Plus, parameter parsing is problematic and unless you get it completely right, very easy to make insecure.
You started with how do you pass a token with HTTP - that’s simple -cfhttpparam. It’s either going to be URL, FORM, or Header.
The more details you give the better answer you’ll get. Even better if you show us your code. Or dumps of the error or errors. Or an example of it working. Or anything.
-G
Yes, the nodejs REST api server and lucee/cf server and code are all on the same ubuntu box.
The REST api server is not a container itself but it references several containers; the lucee server is a container.
Interestingly cfhttp call to the REST api server is now working, pretty odd, previously same process for cfhttp failed to connect. This is good since cfhttp would be more efficient than cfexecute. I’ll start the process of turning all the cfexecute to cfhttp, quite a lot of them.
Much appreciated.