How to find valid app config properties and set up networking

[jonesy]

Hi all,

I've been reading documentation for about a week now, but I cannot for the life of me find the document that says "here's how to get your application to resolve hostnames on the internet and act like a normal server from that perspective". Is there one?

I see lots of documentation about terminals, and I see references to things like 'usr_ip' and 'dns1' and stuff in all kinds of examples, and I even saw that you can list the boundary properties for an application using app config, but there's nothing that says "here are the valid properties you can set for an application, and here's what they mean."

My appliances all seem to have IP addresses, and they can talk to *each other*. However, I cannot, for example, run 'yum install' or 'yum update' on any of them because they will not resolve external host names. Further, I will, of course, be unable to reach my web server (or assign it a DNS name) until it has a publicly routable IP address.

Can someone point me to the proper document?
Thanks!

PS -
Also, a feature request for 3Tera's documentation: get away from Twiki. It's very nice if you're the one *generating* the documentation, but it's horrible if you're a lost end user who has to navigate it. Please. Anything but Twiki. At least something that'll handle simple things like links without camel notation, and simple "next>>" links for multi-page documents.

[pete]

Heya, I'm new here to don't take my word on this, and this probably isn't the correct way to do it, but ...

I had a similar problem - webserver happily served up content, but couldn't initiate outgoing connections. I logged in to my 'out' gateway, and modified the iptables ruleset . IIRC, I used:

iptables -P FORWARD ACCEPT
iptables -t nat -A POSTROUTING -i eth1

Where eth1 is interface on the gateway which connects to theinternal server in question.

You may also find that you need to modify /etc/resolv.conf (on the internal server)

[jonesy]

I think we're talking about different problems. All of the interfaces on my application's web server are non-routable private addresses, and I don't know how to change that, or which interface is the proper one to change...

I was thinking that the public IP was set at the application level for some reason. Maybe the examples got me thinking that.

Either way, being that nobody can use their applications to serve a public audience until it is reachable on the internet, it would seem logical that setting this up is documented, but I *still* can't find it.

I also found the reference applications making reference to the various 'usr_ip' and 'dns1' properties, etc., but I can't find anything telling me how to get this working for *my* application, how to assign IPs, whether it's done at the appliance or application level, or whatever. So I basically have a working environment (for lenient definitions of 'working'), that I can't reach on the internet, so it's pretty useless.

[pete]

I think that's correct though - the interfaces on your web server shouldn't be public IPs. You'd put one of the firewall components (IN and OUT) on either side of it and they would handle the NAT

[Jsmart]

Hello,

what you are missing is setting the gateway attribute on the terminal that attaches to your NET gateway.

this tell the appliance to set a default gateway route in the appliance. it also tells the appliance that this is the default name server.

the NET gateway in our appliance catalog acts as an Internet gateway and firewall as well as a BIND (DNS) forwarder.

you can set this attribute on the terminal using the class editor in the GUI.

I will make sure there is a full description on this topic.

please let me know if this does not solve your issue.

--Jessie@3ter

[PeterNic]

Jonesy, Pete,

1. There is no "common" IP address property that is valid for all applications -- each application defines its own properties. The reason you are seeing usr_ip in the examples is because that's how we have named those IP address properties in the reference applications.

2. To access the Internet -- or to be accessed from the Internet -- an application needs at least one appliance with what we call an external interface (as opposed to terminals which are "internal" interface, internal meaning "within the application"). Most applications have at least 2 such appliances (one for incoming traffic that the app serves, and at least one for outgoing traffic initiated by the application to obtain services from other apps or external services).

3. You can get an external interface in one of two ways:

3.1. Use an appliance that already has an external interface -- all gateways (http://doc.3tera.net/AppLogic2/RefCatalog.html#Gateways) do: IN, INSSL, OUT, NET. For your particular need -- being able to use yum update in an appliance -- you probably will be best served with the NET gateway (http://doc.3tera.net/AppLogic2/CatGatewayNet.html) catalog appliance. The appliance you want to update needs to have an output that is connected to the NET gateway; also that output needs to have the "gateway" attribute set (read more on this in the infrastructure editor documentation, Class Editor, Interfaces tab (http://doc.3tera.net/AppLogic2/RefEditorClassEditorSimple.html#Interfaces)). When you set the gateway attribute for an output, this makes the output the "default gateway" in IP terms; it also sets dns to point that way. (Just a note: if you are changing the appliance --and yum update does that-- make sure it is branched first. This is very important, if you don't know why, ask/read, but please don't ignore this note, otherwise your changes may be lost). If you use this approach, it makes sense to define the IP address properties (typically, net_ip, netmask, dns1/2) on the application boundary and redirect NET's similar properties to the properties on the application boundary -- this is how all the reference apps do it (e.g., Lamp (http://doc.3tera.net/AppLogic2/RefAppLamp.html)).

3.2. Add an external interface to your own appliance and feel free to configure it manually, as you would configure a server. It is beneficial to have the IP address and other settings be given to your appliance as properties (but not strictly speaking necessary). You can enable the external interface from the Class Editor, Interface tab (http://doc.3tera.net/AppLogic2/RefEditorClassEditorSimple.html#Interfaces). Once you do enable it, you will have to make sure you configure it. For one example, see the GSC (http://doc.3tera.net/AppLogic2/RefAppsGSC.html) reference application.

Jonesy: thanks for the feedback on the documentation. I hope the above helps and will serve as interim document until we figure where to put it in the product docs (all the info is there, but not summarized from the viewpoint you were asking about)

Pete: you are right, this is not the correct way; see the note above on branching appliances and using the correct gateway. Please see if the above description clarifies the issue; if not, please post here and we'll work it out.

In any case, we would like to improve the documentation in a way that would have made finding the above information easy. Please post any ideas on this here.

Finally, to answer the original question in the subject line: you can find out what the valid properties of an app are by either (a) opening the app in the Application Configuration (http://doc.3tera.net/AppLogic2/RefAppConfig.html) box (in the GUI, be it from the dashboard's app list or from right-click on the editor canvas), or (b) issuing the "app config <appname> --boundary (http://doc.3tera.net/AppLogic2/CliApplication.html#AnchorConfig)" command. All reference applications (http://doc.3tera.net/AppLogic2/RefApps.html) and all appliances (http://doc.3tera.net/AppLogic2/RefCatalog.html) that come with AppLogic have data sheets in the documentation; the data sheets list all properties and explain what they are for. The forum also has a section for questions and comments (http://support.3tera.net/forumdisplay.php?f=10) on each reference app and/or appliance.

Regards,
-- Peter

[PeterNic]

Hey, if you decide to go with 3.2 above, also see how to configure appliance's external interface in Jessie's post at http://support.3tera.net/showthread.php?t=185.

However, unless you have a very good reason for having an external interface inside your appliance, I would recommend using gateway appliances as shown in the Lamp application (http://doc.3tera.net/AppLogic2/RefAppLamp.html). Your appliance will most likely look like the WEB appliance (http://doc.3tera.net/AppLogic2/CatWebserversWeb.html).

Let me know if we can help further with this.

Regards,
-- Peter

[jonesy]

Thanks for all of this information, PeterNIC. It would've been helpful to see something like "this web server you just created won't be visible from the 'net until you give it an external interface of some kind, which you can do like x, y, and/or z". I have no doubt that all of the information is there somewhere, though :)

I am able to see my web server now, so that's good. Now I just need to figure out how to get my ssh key to work with it (/me curses java terminals)

[PeterNic]

That's easy -- see the command
user set <username> sshkey="...."
(there are just about a thousand postings in the forum on how to do this)

You can, of course, paste the key... it is trickier to do this in a browser, but if you right-click Paste, you can get Help on how to do it.

BTW, the terminal emulator is not Java; the web shell terminal emulator is done all in JavaScript -- and it is the only browser-based shell that I know that can be resized (/me thinks it is pretty cool, although for hard core work there is no substitute for ssh)

Regards,
-- Peter

[PeterNic]

On documenting how to access the Internet from an appliance: if we had something on this in the Appliance section of the Application Model (http://doc.3tera.net/AppLogic2/AdvApplicationModel.html) topic, will that have helped?

Regards,
-- Peter

[jonesy]

PeterNIC -

Two things:

1. I'm not looking to ssh to my controller, I'm looking to scp/sftp files to my web server's content directory. I also haven't decided what form that will take (nfs-mounted or app-level volume). Also, wrt the ssh key - I had read that you could use the 'user set' command, and tried a million times to do it, but I don't *believe* the docs say that once you get the key in place, you have to 'ssh root@my.ip.addr' - I assumed I'd ssh as the user I ran 'user set' on.

I had support put the key in place, and at first, they didn't tell me either. :-P

2. I think that, in the grand scheme of documentation, how to access the internet from an appliance belongs in a whole bunch of places. It's fine to attach it to the NET documentation, but that assumes I even *know* I need to use one of those, so it belongs in a couple of other places as well, and there needs to be probably several really quick 'howto' docs to help people get started. My issue with documentation of AppLogic is the exact opposite of most apps: there's *tons* of docs for AppLogic, but it's kinda written like a novel, and no matter what piece of documentation I look at, it always falls into this lingo about nebulous things that aren't helping me with my current issue ;-P

Grid University is also no help, because I need to get things running more or less *now*.
The Grid Univ. films are also no help, either because the webex url's are invalid (that's what webex says), or because webex doesn't support Firefox on a standard Ubuntu 7.10 installation (that's what I suspect).

Hope this is useful input. I'm trying not to gripe arbitrarily without offering some useful input :-D

[PeterNic]

Jonesy,

I have opened a "bug" on the documentation -- to clarify the unobvious "root" user for the ssh/sftp/scp commands. For reference, the defect number is SCR 2092; I expect it will be fixed along with other defects in an upcoming release and the doc will be re-published. I have also opened a change request to remove all the CamelBack topic names from the human-readable user documentation -- I agree with you that they don't contribute anything to users who read the docs (while I like wikis in general and TWiki specifically, I also dislike the CamelBack notation).

On the Internet access side -- OK, we'll work on this. Aside from the GSC application -- which behaves more or less as a regular server -- the appliance model is new to everyone. What people get implicitly and what they don't is hard to predict and I appreciate all the feedback on the docs. The forums are intended to supplement the doc and seem to be working reasonably well for this (btw, the search function searches both the docs and the forums). The concept and reference docs should also explicitly state that appliances, by default, have no access to the public network.

I expect we'll be adding more HowTo's to the docs -- in addition to the concept and reference docs. Unlike them, the howto's will be ad-hoc, targeted to a particular task and have references to the appropriate concept and reference docs. Many of them will be based on topics raised here on the forums -- the ones people seem to have harder time figuring out.

Many thanks,
-- Peter

PS: Some suggestions for your app (since I don't know the app, some of these may be off):
- for the web server content directory -- if you will be modifying it frequently and while the app is on-line, then the best option is to keep the content on a NAS appliance (use content_on_fs=1). Keep in mind that the content volume for WEB is read-only, so that it can be shared between multiple instances of WEB in the same app (very convenient and secure but limiting in certain situations). Regardless of your choice, the content should reside on an app-level volume.
- if you need the NET gateway only for app maintenance, like yum updates, it may be more secure to make the NET gateway standby and start it *only* while you are doing maintenance. In general, appliances are not supposed to access the Internet unless their role in the application requires it (and for most appliances, it doesn't).