unattended installation WIP

[phryneas]

Hi,

at the current state, the setup process is very interactive and makes active changes in the target system.

This makes it absolutely unusable for an unattended installation via chief/puppet/saltstack/ansible.

In this PR, I am trying to offer a second installation option that

• does not install any packages or change configuration of existing packages
• has no interaction, but receives all configuration options either per environment variable or command line argument

This is far from usable or finished, but I wanted to know your opinon on this. (I haven't even tried to run it so far.)

Do you like the direction I am going with this? Should I do something differently? Should I drop it completely?

Your feedback please.

[jonsjava]

Good idea!

Are you willing to assist with this project? Since I started it, I've moved on from admin to engineering, so don't have as much time to work on non-work stuff. That will change next week, as they want to use my tool in their environment, but I will have to re-tool it for chef to implement in-house.

If you're willing, I'm willing to throw you in back-end.

[phryneas]

No, this is more one of those "I want to install this, but it's completely screwing up my system, so I'm cleaning it up" moments.

I may stick with the project for a while or check back from time to time but I don't have the spare time to really commit myself to another project.

[jonsjava]

I completely understand.

Thanks! I will start working on a cook book for this in the next week.

[phryneas]

I guess by then there will be a working cli installer, which should make that a lot easier ;)

One thing though: I'm a debian/ubuntu guy, so you'll have to double-check the RHEL-specific stuff. I mainly copy-pasted & cleaned that part.

Also you might have a differeing opinion on whether mysql should be installed on the target system.

[phryneas]

Okay. This now requires a ton of command line options, but it should run without having to change too much existing code.

It should be possible to call this with

install.sh --unattended-install --force --db-host [VALUE] --db-root-id [VALUE] --db-root-pass [VALUE] --db-user [VALUE] --db-pass [VALUE] --db-name [VALUE] --new-web-admin [VALUE] --new-web-admin-email [VALUE] --adm-passwd [VALUE] --new-web-duser [VALUE] --new-web-duser-email [VALUE] --usr-passwd [VALUE] --comp-id [VALUE] --your-company [VALUE] --installation-key [VALUE] --relative-path [VALUE] --new-web-dir [VALUE] --web-user [VALUE]

to get a clean install that overwrites new_web_dir.

Still completely untested. Gonna test that tomorrow in the evening.

[phryneas]

short question: is your bash really a bash or is there maybe some derivate symlinked to /bin/bash ?

some things there do not seem to work for me, and I've checked, I'm using bash ;)

[ "${new_relative_path:LEN}" != "/" ];

does not check the last character.

[ "${relative_path: -1}" != "/" ]

does.

the current code just adds another trailing slash as far as I can see

[jonsjava]

Actually, the installer was almost completely written by metalcated. Mine was much simpler, but his was more full-featured, albeit complex.

[phryneas]

I don't want to critizice, but you might consider going back to something more simple.

It's cool, I'll give it that, but it does horrendous things to a system.

It installs packages, sometimes without asking.

It even modifies iptables without asking, which will completely break everything if something like shorewall or ferm is installed.

[phryneas]

Also it is doing a bit too much hand-holding.

I doubt a system administrator really wants a package that configures other packages for him - but that's just my opinion.

In my opinion checking for certain pre-requisites should be enough.

[jonsjava]

I'm fine with change. I do agree it needs to be more aware, and unattended, so with that in mind, when I start my code push next week, I'll do it with that in mind (that, and merging the front-end with vFense back-end, as his back-end does some amazing things). I will keep my back-end, but I will be forking my front-end to work with vFense API calls. This will improve my front-end code while improving the overall look and feel of vFense.

But with all that said about the front-end, if it can't be installed easy, safely, in a sane fashion, and in an automated DevOps approach, there's no real point to it, because it misses the target audience.

[phryneas]

On the automation part, it's going forward.

I'm doing some tests right now and I think with a few more small changes this deploys right from saltstack.

[phryneas]

Okay, It didn't need any more changes, it IS deploying correctly from saltstack.

Here's a salt state if you want to test it (quick&dirty):

patchdashboard package {{pkg}}:
  pkg.installed:
    - name: {{pkg}}
{% endfor %}

{% for svc in ['apache2' ]%}
patchdashboard service {{svc}}:
  service.running:
    - name: {{svc}}
{% endfor %}

patchdashboard mod_rewrite:
  apache_module.enable:
    - name: rewrite
    - watch_in:
      - service: patchdashboard service apache2

patchdashboard apache.conf salt_block:
  cmd.run:
    - name: "sed -i '/<\\/VirtualHost>/i  ###SALT_BLOCK_START\\n###SALT_BLOCK_END' /etc/apache2/sites-available/000-default.conf"
    - unless: "grep -q SALT_BLOCK_START /etc/apache2/sites-available/000-default.conf"

patchdashboard apache allow_override:
  file.blockreplace:
    - name: /etc/apache2/sites-available/000-default.conf
    - marker_start: "###SALT_BLOCK_START"
    - marker_end: "###SALT_BLOCK_END"
    - content: |
       <Directory /var/www/html>
       AllowOverride All
       </Directory>
    - show_changes: True
    - watch_in:
      - service: patchdashboard service apache2
    - require:
      - cmd: patchdashboard apache.conf salt_block

patchdashboard repo:
  git.latest:
    - name: https://github.com/phryneas/patchdashboard.git
    - rev: bde68168753ec5790951fd1051e83e443eb09248
    - target: /tmp/patchdashboard

patchdasboard ssh-keygen:
  cmd.run:
    - unless: "test -f /root/.ssh/id_rsa"
    - name: "ssh-keygen -f /root/.ssh/id_rsa -t rsa -N ''"

patchdashboard install:
  cmd.run:
    - unless: test -f /etc/cron.d/patch-manager
    - name: |
        {% raw %}
        cd /tmp/patchdashboard/; ./install.sh --unattended-install --force \
        --db-host localhost --db-root-id $(sed -n 's/user\s*=\s*//p' /etc/mysql/debian.cnf | head -n1)  --db-root-pass $(sed -n 's/password\s*=\s*//p' /etc/mysql/debian.cnf | head -n1) \
        --db-user testuser --db-pass testpass --db-name testdb \
        --new-web-admin webadmin --new-web-admin-email admin@example.com --new-web-admin-passwd webadmpass \
        --new-web-duser webuser --new-web-duser-email user@example.com --new-web-duser-passwd usrpass \
        --your-company power \
        --installation-key somekeyiguess \
        --relative-path /test --new-web-dir /var/www/html/test/ \
        --web-user www-data
        {% endraw %}

[phryneas]

oh, and please don't merge this, this still needs cleaning up and it just does the installation, no upgrades or anything.

[phryneas]

Okay, that was a tad too early ;)

Now accounts are set up properly and it is possible to log in.

I'm updating the salt formula in place above.

Also, that's it for today.

[phryneas]

okay, in theory this should be it, but it hasn't been tested yet. will do the final testing tomorrow.

[phryneas]

okay. everything should be working now. could you take a look?

[jonsjava]

:+1: adding. Sorry. I've been trying to figure out the best way to proceed. Planning on creating cookbook and test kitchen for this tonight.