dshoreman / servidor

A modern web application for managing servers

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Installer fails at Composer step in Vagrant

dshoreman opened this issue · comments

When the installer reaches the "Installing required Composer packages..." step, it fails either trying to create the cache dirs, or when attempting to install the first package.

Theory:
Vagrant should be mounting /var/servidor as the servidor user (also used to run composer install) so it's not immediately clear why it's failing. Is the user/group ID correct in the Vagrantfile?

Steps to Reproduce:

  1. Delete the .composer directory from project root (if it exists)
  2. vagrant destroy -f to guarantee a clean start
  3. Re-run the installer with vagrant up

Screenshots:

  • Original from @stoppert where it fails to create dirs within .composer/cache:
    image
  • My own test where it doesn't seem to have an issue with cache dirs, but can't write to /var/servidor/vendor:
    image

So it would seem despite using the same Vagrantfile, the UID for servidor can be different on two systems. @stoppert, could you post the output of vagrant box outdated? I wonder if we have different box versions and something maybe changed in them, hence the UID mismatch 🤔


Fixing this properly could prove difficult since the root cause is the initial lack of a servidor user - hence the use of UIDs in the first place. Normally we could run vagrant up and - when it fails due to lack of servidor user - manually provision before restarting the VM. In our case though, failing to mount the share means no installer to create the user, so that won't work.

A couple potential options:

  1. Create our own vagrant box and run the installer there instead

    Pros:

    • We can know the user will exist because the box has servidor preinstalled
    • Changes in the ubuntu box can be accounted for instead of breaking things when one user has a different version of ubuntu/bionic64 than another

    Cons:

    • Another repo to maintain
    • Changing the installer would become a loop of tweak, commit, push, pull into box, destroy && up, repeat
  2. Restructure the code so build/ is in the root and any laravel stuff is inside src/

    Pros:

    • src/ can be its own shared folder with the project root using the (currently disabled) default share
    • Much easier to get to changelog/readme/etc, keeping code separate from CI and general metadata
    • Test/linting/SA tool configs could move back to root so editors can run them without config tweaks
    • Could make it easier to package for various distros, if that ever happens

    Cons:

    • Tons of paths to update in installer and tests
    • Installer could need changes so that it can (optionally?) be ran in two stages:
      • Stage 1 (src/ not mounted) - install software, create the servidor user
      • Stage 2 (src/ is mounted) - composer install, set configs, migrate etc
  3. Tweak the Vagrantfile such that it uses default mount first, then runs the provision script, then replaces the default mount when install is complete

    Pros:

    • Would avoid the need for any major project or installer changes
    • No need to re-provision as it doesn't attempt to mount as servidor until setup has run

    Cons:

    • Entirely hypothetical
    • May not work at all
    • Relies on the assumption that everything in Vagrantfile is done in order and one step at a time

Option 2 might be possible without splitting setup into a two-stage process in non-Vagrant (production) envs. By testing the existence of the servidor user (or src/ mount) in strategic places - no user or src mount means brand new VM so we just create the user, then on second run the mount will succeed and we can skip user creation instead. If that would work, it definitely seems to be the better option long-term, but option 3 would be a wonderful hack in the meantime...

at ~/Projects/servidor on develop 👎
❯❯ vagrant box outdated && vagrant box list
Checking if box 'ubuntu/bionic64' version '20190930.0.0' is up to date...

base (virtualbox, 0)
ubuntu/bionic64 (virtualbox, 20190930.0.0)

Strange that it thinks it's up to date, I wonder if vboxuser etc were added in a later version or something... Before you try updating the box could you vagrant ssh and post output of cat /etc/passwd? Could be interesting to diff it against my (outdated yet... newer than your in date one?) vm

Same error with
ubuntu/bionic64 (virtualbox, 20200930.0.0)

from the new box

vagrant@servidor:~$ cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
systemd-network:x:100:102:systemd Network Management,,,:/run/systemd/netif:/usr/sbin/nologin
systemd-resolve:x:101:103:systemd Resolver,,,:/run/systemd/resolve:/usr/sbin/nologin
syslog:x:102:106::/home/syslog:/usr/sbin/nologin
messagebus:x:103:107::/nonexistent:/usr/sbin/nologin
_apt:x:104:65534::/nonexistent:/usr/sbin/nologin
lxd:x:105:65534::/var/lib/lxd/:/bin/false
uuidd:x:106:110::/run/uuidd:/usr/sbin/nologin
dnsmasq:x:107:65534:dnsmasq,,,:/var/lib/misc:/usr/sbin/nologin
landscape:x:108:112::/var/lib/landscape:/usr/sbin/nologin
sshd:x:109:65534::/run/sshd:/usr/sbin/nologin
pollinate:x:110:1::/var/cache/pollinate:/bin/false
vagrant:x:1000:1000:,,,:/home/vagrant:/bin/bash
ubuntu:x:1001:1001:Ubuntu:/home/ubuntu:/bin/bash
mysql:x:111:116:MySQL Server,,,:/nonexistent:/bin/false
servidor:x:999:999::/var/servidor:/usr/sbin/nologin

Thanks, looks like vboxadd and mysql are the two key differences:

32,34c32,34
< mysql:x:111:116:MySQL Server,,,:/nonexistent:/bin/false
< servidor:x:999:999::/var/servidor:/usr/sbin/nologin
<
---
> vboxadd:x:999:1::/var/run/vboxadd:/bin/false
> servidor:x:998:998::/var/servidor:/usr/sbin/nologin
> mysql:x:111:115:MySQL Server,,,:/nonexistent:/bin/false

I guess it counts back from 999 when creating a system user manually which would explain why servidor gets 998 for me, but 999 when there's no vboxuser... No idea why the mysql group ID is different though 😆

@stoppert All the installation issues should be fixed in #278, could you try the installer-fixup branch please and let me know how it goes? Once you've checked out the branch use make dev-env instead of vagrant up.

In theory, it'll take care of the system user, composer install and npm/asset stuff too so after make dev-env it should run in a browser with no extra steps

ezoic increase your site revenue