Help understanding what Ubuntu user(s) should be used

[Mesuva]

Hi everyone,

I've been investigating using deployer to better manage updating a Laravel app.

For testing, I've been using UTM to spin up an Ubuntu 24.04 server, connecting to it locally, which has been great for repeating things from a clean start. I have no issues understanding the broader concepts of deployer, I can write my own commands, etc, and I've been able to deploy successfully from a github repo.

But what I've struggled with understanding is what are the best practices when it comes to creating the initial user on the Ubuntu server, and what user should be handling the provision step.

When I first install Ubuntu, it asks to create an initial user, and that user has sudo privileges. I'm enabling the SSH server, and I can then ssh into the box using that user.

My questions are:

• should I be creating that initial user with the username of 'deployer'? Or can I name this anything?
• is that the username I should then dial in to ->set('remote_user', 'deployer')?
• when I then run dep provision, is the expectation that with a standard Ubuntu install I'd actually be running the command as dep provision -o become=root?
  When I do that, I get prompted for a password, and after entering it a few times it fails a permission on the command cat /etc/os-release, which makes me think I have to be running the command as proper root. If I run just as dep provision, it also keeps prompting for a password, even if I've configured my public key. I can run dep ssh and log in without any prompts.
• Do I need to do anything else like a NOPASSWD option for the deployer user?
• Or should I be running dep provision -o provision_user=deployer -o become=root?
  That gets further, but I still hit permissions errors relating to the use of chgrp
• Or, should I be enabling root on the server to log in using a password?

I'm wondering if there's a few assumed steps with setting up the Ubuntu server, that simply aren't included in the doco, but they're steps that are critical to make the initial provision set work.

The doco gives an impression that I should be able to just spin up a Laravel server, create a deployer user that can sudo to become su (which is going to be initial user you create), and then just run dep provision -o become=root and that's it. But that simply doesn't appear to be the case.

Please note, that's not criticism of the doco, I understand it needs to cover a wide range of use cases!

Finally, I am confused by this phrase:

If your server only has a root user, the provision recipe will create and configure a deployer user for you.

Ubuntu doesn't have root access by default, so I'm not sure of where this would come into play. Would this be where you do enable the root user to be able to log in, get things setup, then disable it again? If that's the case, it feels more work than just creating a new deployer user.

Any guidance on this would be appreciated.

[antonmedv]

should I be creating that initial user with the username of 'deployer'? Or can I name this anything?

Nope, dep provision will create deployer user automatically.

is that the username I should then dial in to ->set('remote_user', 'deployer')?

If you use dep provision, yes - deployer user. Or use the one you created if you going to provision everything yourself.

when I then run dep provision, is the expectation that with a standard Ubuntu install I'd actually be running the command as dep provision -o become=root?
When I do that, I get prompted for a password, and after entering it a few times it fails a permission on the command cat /etc/os-release, which makes me think I have to be running the command as proper root. If I run just as dep provision, it also keeps prompting for a password, even if I've configured my public key. I can run dep ssh and log in without any prompts.

provision should be run with root user. If you can not ssh with root user, ssh with different user and become root (for that sudors should allow to become root for this user).

Do I need to do anything else like a NOPASSWD option for the deployer user?

No. If you use caddy this is enough to reload config.

Or should I be running dep provision -o provision_user=deployer -o become=root?

Just run with root. This is the easier.

Or, should I be enabling root on the server to log in using a password?

Enable root, but login with ssh key. provision should be done only once.

[jsonallen]

provision should be run with root user. If you can not ssh with root user, ssh with different user and become root (for that sudors should allow to become root for this user).

Maybe I'm missing something The above statement seems to imply that you can in fact configure deployer to use a non-root user so long as the user has sudo privs. How is that configured on the deployer side? I've tried a few different things and it always tries to ssh to the remote server as root.

[jsonallen]

@Mesuva I think I figured it out. To provision as a non-root user, e.g. a fresh Ubuntu install, you can use the following in the deploy.php

host('host.example.com')
    ->set('provision_user', 'ubuntu')
    ->set('remote_user', 'deployer')
    ->set('sudo_password', '')
    ->set('become', 'root')
    ->set('deploy_path', '~/deployer')

[Mesuva]

@jsonallen I'm pretty sure I tried that, but it hit permission errors.
It's like it wasn't actually becoming the root use, it was running things with sudo, but then it hit a command without sudo and failed.

In the end I'm just enabling root login for the provision step, using that, then disabling it afterwards.

[jsonallen]

Interesting. The entire provision process worked for me without errors on a fresh Ubuntu 24.04 install on AWS using the stock ubuntu user.

[Mesuva]

I did my test using a local virtual machine, using an install ISO, where you set up the initial user (who then is a sudoer).
Perhaps the AWS Ubuntu image sets that initial ubuntu user up slightly different.

Good to hear it worked though!