Retrieving the Server's IP address

Possibly I’ve overlooked something, but on a shared system is there a way for a client to find out what the server’s IP address is?

I imagine I could work something out but so far the means has eluded me.

I don’t understand this question. Sharing clients reference the server by name. If the server is on the same network, then Bounjour is used internally to convert the name into the IP address. If it is a remote server, you have to manually configure the name and IP address.

Perhaps you want a sharing client to have code that accesses the web interface of the server?

This doesn’t actually return the IP address, but rather the URL (which would usually include the domain name, not the IP). I’m not sure why you would need the actual IP address. Panorama doesn’t have a feature to resolve a domain into an IP address, but I’m sure there is a shell command that will do it if you actually need that.

I have a number of reasons for desiring the IP address, for instance, there are times that I want procedures to be run on the server, not on the client. So using posturl( or similar is an easy way to do it. Rather than hardcoding the server address, I’d like to have it discoverable, making it far simpler to port files and/or procedures to other shared setups.

Some weeks ago I was attempting to do this using dbserverdomain( but found it only works on the server machine itself. Just now I determined that panoramaxserverurl(servername(“”)) does get a URL but it’s not necessarily usable without careful parsing. For instance, I’m getting the likes of http://myserver.local.:8080 and I’m not sure what would be returned if there are multiple domains on the server.

The server is certainly capable of determining what its IP address is. Getting it to share that with the clients is the challenge.

The IP address is clean and simple but apparently not easily attained.

Earlier today I tried it via a server variable. It seemed that if I could get .InitializeServer to load a server variable with the server’s IP address that could be a solution.

Sorry to say I ran into all sorts of server variables issues, even when not using .InitializeServer.

For instance, in spite of numerous ways that I attempted to create this or other server variables, I can’t make svIP exist and the db is confirmed as shared:

Even after quitting PanX and the Server, I get this:

Same with servervariables(“”)


So as I suspected, you do not need the IP address, what you need is the URL.

Whatever you get from the panoramaxserverurl( function is by definition usable. This returned URL is what the sharing code is using – internally, it’s then using that to communicate with the server using the url( or urltask( function. It would also work fine with the posturl( function (but see the note below). If this URL wasn’t usable, the client wouldn’t be able to connect with the server at all.

You don’t specify, but I’m guessing that you were trying to use defineservervariable and servervariable( on the server itself. However, this operations only work on the client. The idea is to be able share values between different clients. You cannot access or modify server variables in web code, or in .InitializeServer (or any code that runs on the server).

This is the same as Panorama 6. I’m surprised this never came up before. At a minimum, I should update the documentation to indicate this restriction. Or, it might be possible to actually make it work – I can see how that could sometimes be useful. However, this wouldn’t be a “fix” – some entirely new code would be needed to make it work.

In any case, the solution to your problem is not server variables, but to use the panoramaxserverurl( function, as I described above.

url( vs loadurl( vs posturl(

Panorama 6 had separate statements for HTTP GET [loadurl] vs. HTTP POST [posturl] operations. These statements are still available in Panorama X (and also corresponding new functions with the same names), but there is also a new url( function that can perform either GET or POST operations (and also PUT, DELETE, etc.). Under the hood all of these functions use the same underlying code, so there’s no performance advantage to use one or the other. However, the url( function is much more flexible than the older functions. It allows you to specify options like timeout, cache policy, and user authentication. The design is flexible so in the future even more options may be available. So personally I always use url(. I’m mentioning this in case you (or anyone reading this) didn’t notice that the url( function could perform POST operations.

Also, I just noticed the documentation for the parameters of the posturl( function is completely wrong! :scream: I wonder how you even figured it out.

true() – false()

I noticed this line in your code:

If dbshared() = -1

It’s considered good practice to avoid constants like that when possible, so you might use this instead:

If dbshared() = true()

Or, this also does the exact same thing:

If dbshared()

I did try to use the server variable on the server. BUT, the problem in creating server variables has persisted for me.

If I’m doing something wrong on this shared client base, I’m failing to recognize my error.
Screen Shot 2022-10-14 at 7.58.52 AM

Borrowing an example from the Help file:
Screen Shot 2022-10-14 at 8.06.30 AM

Yeah, I had hard time but I really do try to figure things out before I turn to posting here. I guess I managed on that one. As I noted though, I’m aware of the alternatives and had been trying them too in my quest for the server’s IP.

FWIW, I deleted Pan Server (after preserving Public Databases) and the reinstalled copy still has the errors on server variables.

If that really is an example from the help file, it is wrong. I cannot find that code anywhere in the help file though – could you tell me where you saw it? The correct code is:

defineservervariable "DefaultAreaCode","714"
message servervariable("DefaultAreaCode")

As you can see, you must use the servervariable( function to access a server variable, you can’t just put it into a formula as you would for “regular” variables.

FYI, the server variables are stored inside the corresponding database on the server. So if there actually was a problem with a server variable (there wasn’t), the problem would be retained by preserving the contents Public Databases folder.

In this case, however, everything’s fine on the server. If you use the code:

message servervariable("DefaultAreaCode")

You’ll find that “714” was correctly stashed on the server.