Mix phx.new and phoenix.new error in FreeBSD

Just went to create the first app on a freebsd 11 digitalocean droplet and:

mix phx.new

and

mix phoenix.new

both give an error like:

* creating myapp/config/config.exs
** (File.Error) could not make directory (with -p) "myapp/config": no such file or directory
    (elixir) lib/file.ex:208: File.mkdir_p!/1
    (mix) lib/mix/generator.ex:29: Mix.Generator.create_file/3
    lib/phoenix_new.ex:545: anonymous fn/5 in Mix.Tasks.Phoenix.New.copy_from/3
    (elixir) lib/enum.ex:1755: Enum."-reduce/3-lists^foldl/2-0-"/3
    lib/phoenix_new.ex:532: Mix.Tasks.Phoenix.New.copy_from/3
    lib/phoenix_new.ex:233: Mix.Tasks.Phoenix.New.run/4
    (mix) lib/mix/task.ex:294: Mix.Task.run_task/3
    (mix) lib/mix/cli.ex:58: Mix.CLI.run_task/2

That’s as the default freebsd user that is created when a droplet is created.

If I su to root, this is the result:

** (Mix) The task "phoenix.new" could not be found

Have I installed elixir/erlang as the wrong user?

Is this a permissions related error?

I had this before upgrading to 1.3. Is it normal to see both mix phoenix.new and mix phx.new after upgrading and running:

mix --help

mix phoenix.new       # Creates a new Phoenix v1.2.4 application
mix phx.new           # Creates a new Phoenix v1.3.0-rc.2 application using the experimental generators

Thanks

1 Like

When you su root you will probably don’t have the phoenix-archive in roots ~/.mix, you will need to reinstall the archive as root (which is not what I’d recommend).

Usually you do not even need to have the generators at all when deploying to a host, they are only meant to be used for development.

Just build a release, push it to your host and run it.

If though, you wan’t to use that machine as build and stage server, there is still no need to have the generators available. Just check out from source control and cd into the source folder and run the usual test and compile tasks after doing mix deps.get.

1 Like

In which directory are you running the generator command? Perhaps it’s one which is not writeable to the default user.

ls -lah run from within that directory will show you the permissions.

You could make a new directory for the app as root/su and then chown it to the non-root user.

The directory I’m trying the commands in is:

/usr/local/www

755 drwxr-xr-x 3 root wheel 512B Jun 21 23:30 www/

It was 555 by default, but used chmod to change to 755, recursively.

This still doesn’t help, as the freebsd user can’t make a directory in it, although it’s part of wheel group.

I’d rather not change the www directory to be owned by freebsd:freebsd.

And, I can’t (and shouldn’t run) mix as root in the www directory.

I must be thinking/doing something wrongly.

Thanks

Thanks, but I’m trying to create a new project from scratch - not from source control, using mix phoenix.new or preferably, mix phx.new.

What user do you usually run elixir/mix/phoenix as?

Just as an aside, this is interesting (although not entirely relevant to this discussion and my problem): Phoenix as a Service on FreeBSD.

755 means, that owner is allowed to do anything, group and other are only alolowed to read and “execute”, to actually create a directory, you need have “write” enabled, which is the second bit of each triplet.

Also usually you do not put a phoenix project under /usr/local/www, in many default configuration I have seen that is the web root and serves as is. So if you did it there, I could fetch your sources file by file, but your phoenix application wouldn’t even be touched by any of my requests.

It depends. During development I do it as myself, but not on a public server.

When deploying, I do run mix on my build server as the build user and deploy only the created artifact, which then is run as a service user.

I have to admit though, I haven’t deployed phoenix so far, nor did I deploy anything which were publicly available. All my services I wrote using erlang and or elixir are inhouse only.


I strongly suggest to stop what you are trying to achieve right now, take a step back, develop locally, learn OTP, learn releases and after you have finished that, then you can go on and do proper deployments.

Maybe even learn some “*nix” before that…

As @NobbZ described, other group members don’t have write access to the ‘www’ directory due to the second digit of 755 being 5 and not 7.

Assuming you want to go ahead with creating the new project on the droplet, and you won’t be serving the entire /usr/local/www over the web, how about something like:

$ su
# cd /usr/local/www
# mkdir my_projects
# chown freebsd:freebsd my_projects
# exit
$ cd /usr/local/www/my_projects
$ mix phx.new project_a

Or just put the project directory somewhere in freebsd’s home directory?

1 Like

If he wants to stick to developing on that droplet at all, he should definitively go with $HOME.

I do not think that any user that has a homedir below /home should do anything outside of it.

1 Like

I use the www dir as convenience - I create it as I’m not running nginx or apache, so it’s not created by installing one of those servers - and I point my reverse proxy to www/myapp/ as the root dir.

That’s probably doing it wrongly, but I’m not doing a standard release, and I’m unsure what the convention is for directories in my situation because I’m running phoenix as a service/daemon that I could create a user. I guess I could have it running as the nobody account? (I included the link above because it does things differently, or at least, I haven’t understood it enough yet to see how I can apply it to my situation.)

Can you please suggest the user I should create, the directory structure, and how I should create a new phoenix web app via mix without doing a proper distillery/exrm release?

I would like to build up to doing that but I have a lot to learn at this time and prefer to not run a VM on my dev machine as it’s not the fastest, so I’m setting up a droplet for testing/staging and just small websites with client logins as I build out my own CMS for them.

I feel I know enough nix - am not confused about permissions/etc - the concepts from sticky bits to user groups, etc - but I’m not sure how to apply all that to set up the right user for elixir/erlang/phoenix to run in this situation.

I’ve done it successfully with PHP, straight-up .html, etc, with nginx etc, but I’m trying to find the right way to do it with phoenix.

To launch a simple website, I don’t have to use phoenix, but I plan to explore OTP etc after I have got more simple servers and sites launched, for my own app.

My use case may not appear that important as I’m not using the full power of phoenix yet, but to me and likely millions of other compsci students, being able to create either a local VM or a droplet and quickly run phoenix on each for sandbox/scratchpad dev, the odd client job, and testing ideas for future apps, it is important and phoenix appears a great ‘base’ to use.

OK, I du understand the desire to not develop locally in your case and as well accept it as an hard requirement, still you could dual boot your own machine and also work during bus times.

Still lets talk about phoenix on your droplet:

Since you want to develop and host on that machine, I’d develop as the default user in its $HOME, you could even use SSHFS to blend the remote stuff into your own filesystem and use your local editors and stuff. Depending on your network speed it might be slow though and there might be other remote FS available which suite you better.

That development phoenix can listen on a port only known to you, something random. Delivered directly, without a reverseproxy or stuff. But shut it down after you have finished your development session.

Track your development in git, hg, or darcs (or any other DVCS) and push into a well known upstream repository hoster which allows you to have private repositories, this is meant as a back up strategy primarily, later on you will learn all the other usefullness after you have used it a while.

Whenever you have achieved something that you want to publish, just build a release, push it into the appropriate folder (often /usr/local/bin for non-upstream-repository-software) and create a systemd unit to start it (well, or a script for whichever init system you use).

You can name the user used for running the phoenix stuff however you want it to, but I’d name it either $your_app_name, phoenix, or www, this way you can easily see what that user was created for.


Also I’m not sure if I had created a freeBSD droplet, since freeBSD is known to be special. I had choosen either a Debian, Ubuntu, or your schools distro. The first two have great communities and you will find help online. The last one should be that one which you feel comfortable with and which you can get support for in your university. Were you can grab a friend and ask, or a professor, or even your universities unix sys-op.

Please ignore my last paragraph when your school uses and teaches freeBSD :wink:

1 Like

Thanks for all your help - I’ve got phoenix running.

However, I’m struggling to config phoenix right so that I can see the page it serves up.

I get this in my nginx error.log:

connect() to xx.xxx.xxx.xxx:8080 failed (61: Connection refused) while connecting to upstream, client: xxx.xxx.xx.xx, server: myapp.tld, request: "GET / HTTP/1.1", upstream: "http://xx.xxx.xxx.xxx:8080/", host: "xx.xxx.xxx.xxx"

When I run:

mix phx.server

all appears well:

Running myapp.Web.Endpoint with Cowboy using http://0.0.0.0:8080

Do I need to configure cowboy to run on the ip address of the backend (upstream) server that it is running in?

Thanks, now I’ve got my reverse proxy to phoenix server working, I’ll try following your advice and setting things up properly as releases.