Remote API?

[thepenguinmaster]

Hello,
I am new to the forums, and FreeNAS. I have done a little bit of research on the topic and setup a few FreeNAS systems in different environments. I want to attempt to create a system that uses FreeNAS but it will require remote management of the FreeNAS system. I don't really want to have to go through SSH and parse out responses and such as it can be inconsistent or return unexpected results which can be difficult to handle programmatically.

Is there an API that can be accessed externally (SOAP or REST) as a web service or a plugin that will allow me to do this? I would prefer to not need to write my own plugin as it will add a lot of development time to the project. I would like to be able to manage/create iSCSI targets or file shares.

I am sorry if this topic is already covered, but if you could direct me to a link providing some insight or a start, it would really help me out.

Thank you,
Thepenguinmaster

 

[ben]

There is no API for FreeNAS at this time other than the plugin jail, certainly not one for the UI. The UI supports HTTPS remote management already, is this insufficient for your needs?

 

[jgreco]

You appear to have a very unusual view of SSH. Parsing out responses is probably not what you ought to be doing with it. It would be helpful for you to understand that under the sheets, FreeNAS is mostly a layer on top of UNIX, which is a command-line oriented system. ssh gives you raw access to the innards. It would be substantially simpler than any SOAP or REST interface that would still need to handle "unexpected results," so avoiding ssh for that reason makes little sense.

 

[thepenguinmaster]

There is a large difference between SSH and a consumable web interface. When a request is made, a response is issued. It is a very clean interface, hence why everyone uses is and it is a standard. With SSH, there is no way to ensure a reliable protocol because status and error text could potentially sent back as can occur with some SANs. I have controlled SAN boxes using ssh and it is not clean. I am well experienced with the scenario with other solutions. My experience is with a few different models of the PS600 series servers. Thank you for your response jgeco, but my need is justified and stating that it is not necessary is not an adequate answer. Perhaps for this project to work I will need to come up with a custom solution.

Ben, Thank you for your response. I plan to have a software that interacts with the FreeNAS server that will automatically provision services (mainly iSCSI) to customers. to do this, they would be presented with one of my pages or programs that will provision a set of components, one of which is going to be an iSCSI target. The web interface that is packaged with the software is great but I would prefer not to screen scrape the site, generate post backs, and deal with parsing the html. That will be a massive performance hit. If everything can be controlled internally, perhaps I can create a web service on the system and have that issue commands for provisioning. This will however, require quite a bit of extra work.

 

[cyberjock]

It sounds to me like you are looking to make a project that should be created from FreeBSD itself and not FreeNAS.

 

[jgreco]

Most service providers of any size at all find command line access to be an ideal tool for automated provisioning; ssh is simply a tool to allow access to the command line of a remote server. This is why this is commonly used for management of large server farms.

Managing services through Web interfaces is generally problematic in the long run, because eventually someone "Changes Something(tm)" and then something that you tested and knew to work at one point no longer does because now everything is supposed to be using HTML7 but your code implements HTML4 and you get silent failure or similar problems.

In many cases, the Web interface you are talking about merely acts as a wrapper to run scripts and executables. UNIX is fundamentally organized around the command line and script model. Correct use of ssh allows transparent and secure implementation of functionality between platforms. If you aren't using it correctly, then, yes, you could certainly make a mess and it would be extremely unpleasant to use.

 

[jgreco]

It sounds to me like you are looking to make a project that should be created from FreeBSD itself and not FreeNAS.

Using FreeBSD to implement what he wants would probably mean figuring out how to use the command line interface and SSH.

 

[thepenguinmaster]

Just to clarify, by web service I am referring to a JSON service provider that can be consumed by another application on a remote server. It would have been nice to have this as I could easily integrate it into the current design. I think for the cleanest and fastest solution I may end up trying to setup node on the server, then creating a JSON service provider that executes scripts on the NAS. JSON can be made to be secure, simple and clean. Also one benifit to JSON VS SSH is that I dont need to maintain connection. I can simply handle one off requests without the full process of connecting via SSH. There are of coarse other benefits too, which I may discuss later.

I understand that most service providers use command line to control the services, but I am trying to create a new system, not implement an existing design. For technology to evolve, you have to put aside what others are doing and improve upon existing designs. The reasoning for the requirement is my own, and I really do appreciate alternative suggestions. I will use them in the future, but for reasons I cant share, I will need a consumable JSON service on the box.

Thanks for the suggestions! If I complete the JSON service in a reasonable amount of time then I will share it with the community. I think it will really add to the value of FreeNAS, which is already an outstanding system.

 

[William Grzybowski]

FreeNAS trunk has implemented a REST API for most models however this will not be public available yet (just for internal use). There are plans to extend the REST API and add JSON-RPC or SOAP, however this will take a long time IMHO.

 

[thepenguinmaster]

Perfect! I cant wait to see how it works out. I cant help but to wonder what a long time is in your opinion. Is this years? Months? I will be waiting patiently!

 

[ptan]

FreeNAS trunk has implemented a REST API for most models however this will not be public available yet (just for internal use). There are plans to extend the REST API and add JSON-RPC or SOAP, however this will take a long time IMHO.

Hi William,

Could you pls give me some advice on how to add a new FreeNAS REST API? Thanks.

 

[Dennis K.]

The API can be found here: http://api.freenas.org
Examples on how to use the API can be found here: http://doc.freenas.org/index.php/Section_5:_Using_the_FreeNAS®_API

 

[ptan]

The API can be found here: http://api.freenas.org
Examples on how to use the API can be found here: http://doc.freenas.org/index.php/Section_5:_Using_the_FreeNAS®_API

Thanks. But I'd like to add some new API for my own reason, rather than using the existing API.

 

[fracai]

Then you're going to have to edit the FreeNAS source, compile your changes, and install the resulting image.

What do you need that isn't supported? You can always request that the functionality be added.

 

[ptan]

Then you're going to have to edit the FreeNAS source, compile your changes, and install the resulting image.

What do you need that isn't supported? You can always request that the functionality be added.

I'd like to manage lots of FreeNAS servers, and in my management server, I want monitor the operation characteristics, like memory use-rate of FreeNAS server, connected clients to a specified share.

 

[Kruger]

Like ptan, we'd be looking at adding functionality that monitors that status of replication tasks, date&time stamps of local/remote snapshots, scrubs, overall disk/volume health and end-to-end connectivity, which will essentially form part of a client dashboard. Nexenta (for us) has its own set of issues. Access to the FreeNas/TrueNas API would provide us with a development path, that could see us moving away from Nexenta and onto TrueNas. Currently Nexenta handles the front-end reporting and connectivity sides of things, but its not without its own limitations. Thus moving away from it would require an alternative that offers additional functionality.