ispconfig-cli bash CLI tool merged, feedback needed

Discussion in 'Developers' Forum' started by Johan Ehnberg, Apr 24, 2018.


CLI output format?

  1. Selectable by switch

  2. Pretty JSON

    0 vote(s)
  3. Simple lists

    0 vote(s)
  1. Johan Ehnberg

    Johan Ehnberg New Member

    Hi all,

    I would ask for your feedback on the new CLI tool that was just merged (my first post and howtoforge does not allow me to add a link) go to gitlab ISPConfig3 master branch under remoting_client/cli and check out merge requests !770 and !771.

    Since the CLI tool has been requested a few times before, I hope to hear more about the use cases where it would have been handy in order to finalize the design to be as useful as possible.

    The key questions are:
    - How much validation would you expect from the tool? For example, when specifying a trailing zone and forgetting the trailing dot?
    - When there are trade offs between features and ease-of-use, which way to go? For example, automatically updating a DNS A record when trying to add an existing one versus supporting multiple A records?
    - Output format, pretty JSON (see dns_rr for example) versus simple lists (see dns_as for example)? Or selectable by switch? When using raw methods, the output is always JSON.
    - Bash code review; naming conventions (now using several to avoid collisions), structure, subshell and return data improvements
    - How much use would there be for meta-functions which do not have method counterparts? See for example the current dns_cnames.

    Feel free to also test the tool already and report any bugs. I am inviting more developers to join in the effort - adding functions is very fast and pleasing work. For example, the above mentioned dns_cnames function is a single, simple row of added code. Comment here or drop me a message on johan at molnix dot com if you want to work with me on this tool.
    till and Jesse Norell like this.
  2. Well-Known Member HowtoForge Supporter

    I selected by switch since there may be change in needs over time and usually you could make it modular in code.
    Send data to different functions creating xml,json,human readable.... data
    Johan Ehnberg and till like this.
  3. Johan Ehnberg

    Johan Ehnberg New Member

    That makes sense. The script is highly modular already in terms of using functions internally. One of them is the output.

    One thing I could use some help with is preserving jq's pretty coloring, as it disappears when jq is not the one pushing to stdout.

    Another could be from ISPConfig devs to advise on if there is a good approach to choosing and structuring results to be presented since the output JSON filter needs this. Usually the relevant target is in .response but in many cases we also need rely on individual array items.

    Any thoughts?
    Last edited: May 8, 2018
  4. Johan Ehnberg

    Johan Ehnberg New Member

    Do you have any use cases that you could share?
  5. Well-Known Member HowtoForge Supporter

    Color? like in command? However use cases hmm human readable seems obvious however
    human may want to use this to save some work in automating things and use this for his processing ( function call in other tools or sending reports after executing via mail to human or analyzing machine ).
    To check what worked/what was done it would be good to have a machine readbale output.

    Another thing, do you stuff everything into that cli tool? dns,mail,database,web,backup... ?
    I'd put modules into files which can be sourced by main bash uh and instead of 500 echo commands, maybe use heredoc?
    Just took a glimpse on the script, maybe it's overkill - depends on the goal I guess
  6. Johan Ehnberg

    Johan Ehnberg New Member

    Yes, like that, although jq doesn't do rainbows :)
    The plan is indeed to have all the methods to the tool itself. Most of them are one-liners so echo is more space efficient. That said, I'd prefer to have more people writing the methods.
  7. Jemt

    Jemt Member HowtoForge Supporter

    A CLI would be greatly appreciated. Frankly the REST/SOAP interface is not something I would use, mostly due to extremely poor documentation. We actually have to read through the code to use it, and even then I'm too nervous to use it when it's not even documented properly. My guess is that it has been really poorly tested too when nobody knows how to use it.
  8. till

    till Super Moderator Staff Member ISPConfig Developer

    You can find the API docs for the SOAP remote API in the remote_client subfolder of the ISPConfig tar.gz There you can find also plenty of examples on how to use the API.And btw, the cli tool uses the remote API as well, just the REST-like version which provides the same function calls with same parameters than the SOAP version.
  9. Johan Ehnberg

    Johan Ehnberg New Member

    Jemt, I agree with Till - the docs are quite OK. And this may be a great opportunity to improve them where necessary. Part of the commits so far are in fact documentation additions for the REST API. But indeed the CLI should make it easier to automate ISPConfig without having to work at API level. So it would be interesting to hear about what you would like the CLI to be capable of?
  10. Jesse Norell

    Jesse Norell Well-Known Member Staff Member Howtoforge Staff

    Initiate resync of things (alternative to the gui resync); of course all the main functions like add/update/delete a client, domain, site, mailbox, etc.; maybe add additional php versions; be able to enable letsencrypt for a site. I would love the ability to manage client control for a site/email/dns zone/everything (IE where you accidentally edit a site as admin, then have to edit database tables to give the client control over their domain again).
    ahrasis likes this.

Share This Page