hexparrot / mineos-node

node.js implementation of mineos minecraft management
GNU General Public License v3.0
334 stars 170 forks source link

Working on broadcast-local as a server property. #22

Closed flareofghast closed 9 years ago

flareofghast commented 9 years ago

i think there is an issue using whoami as it gets github user details if you're configured for github. It might be better to just use process.env.USER instead of whoami?

flareofghast commented 9 years ago

I'm having a little trouble getting the server to work. I am now using an ubuntu 14.10 64bit VM system where I have managed to get mineos-node running. I navigate to /admin and start can't download and create a profile. No worries, I terminate and then start with sudo node webui. I download the profile success (I guess that emulates a root login?). I then terminate and start the webui as MC and go to create a server, access denied. What is the proper way to currently run this?

flareofghast commented 9 years ago

OK, I am running as root and mostly things are working.

what's with the bunch of errors after a command?

[fred] received request "start"
server_fin { command: 'start',
  uuid: '3fd4be70-ec85-11e4-89b5-f39baa485d5f',
  time_initiated: 1430101777367,
  success: true,
  err: 0,
  time_resolved: 1430101777483 }
[fred] ::ffff:192.168.196.1 requesting server at a glance info
error: { [Error: connect ECONNREFUSED]
  code: 'ECONNREFUSED',
  errno: 'ECONNREFUSED',
  syscall: 'connect' }
hexparrot commented 9 years ago

Right now authentication is being worked on, (as in right-right now), so it feels a little clunky as of a few days ago when the use of 'root' really became more prominent.

As of this moment, commit 08c2e98a055ffb784e5f32b150985bb4f8845ee3, the webui.js is intended to be run as root, with the existence of a user that matches GID and UID 1000.

In webui.js, the credentials all servers are made with is userid.uid(whoami) || 1000, which is another way of saying "if the user who started the webui is root, default to UID 1000).

This webui runs 100% as an unprivileged user (say you were using UID 1000 or even 1055), but where your create is failing is that your respective user does not have permissions on /var/games/minecraft/{servers,archive,backup} to make the live directory.

TL;DR: nonroot use of the server works IF the user running the web-ui has already created AND has write permissions on /var/games/minecraft

root use of the server works IF an unprivileged user UID 1000 exists.

Again, all of this will be moot once authentication is pulled in, which is kinda working, but kinda not. Issues unrelated to auth, but instead expressjs

hexparrot commented 9 years ago

OK, I am running as root and mostly things are working.

what's with the bunch of errors after a command?

[fred] ::ffff:192.168.196.1 requesting server at a glance info error: { [Error: connect ECONNREFUSED] code: 'ECONNREFUSED', errno: 'ECONNREFUSED', syscall: 'connect' }

This error is 'connection refused'--it happens when MineOS sees that the Java process is in fact running and then tries to poll it for the ping() info. However, the Minecraft Jar itself doesn't turn on it's listening capabilities for quite some time after startup--it's doing a lot of pre-work before it listens to pings. This is the result of Minecraft saying "no I'm not ready yet". It is expected to not show up on subsequent attempts (because the jar will respond properly).

hexparrot commented 9 years ago

i think there is an issue using whoami as it gets github user details if you're configured for github. It might be better to just use process.env.USER instead of whoami?

I can't imagine how it would get github user details...none of that sort of behavior should be coded in at all. whoami doesn't seem to have caused me any trouble so far for any users, but again--once the authentication module is working as expected, the prescribed way to work the server is root-run, non-root login in the web-ui.

flareofghast commented 9 years ago

whoami https://github.com/afc163/whoami

var whoami = require('whoami');
// In a git directory, would be git user and email
//   afc163 <afc163@gmail.com> 
// Otherwise, would be
//   process.evn.USER

If you look at the code it doesn't care if you're in a git directory, the command git config --get user.name works anywhere if you have git set up.

hexparrot commented 9 years ago

Ack, what an oversight on my behalf! I'd never noticed that whoami was really first attempting to return the git user... on both my development VMs, I suppose I hadn't set any git global user info, so it had always fellback to process.evn.USER and I'd never noticed.

Strange that whoami (which I would've predicted would have merely matched the normal command whoami) decided that git details were the important bit.

I'll go ahead and change up the reference. Still struggling on the auth module, but hopefully all this will be moot soon.

flareofghast commented 9 years ago

What did you decide on for authentication? Local users again?

hexparrot commented 9 years ago

Local auth. For the most part, trying to get it to work with socket.io+express.js has halted all coding for like 3 days now.

flareofghast commented 9 years ago

looks like you made some commits to the master branch by accident. I get ./auth dependancy error.

hexparrot commented 9 years ago

Ever since I started working on auth, I've gotten 4 days of no meaningful commits. Quite frankly, I'm just burnt out on how convoluted express.js + socket.io is with auth.

Remember, you don't need to make pull requests on hexparrot/mineos-node. More often than not, collaboration on repos work with making a fork, making commits, etc., etc., and then making a pull request from the fork. This gives you the full opportunity to make any amount of large or small changes, make changes that don't require my direct involvement, and then we can work it out from the PR the best way to get all improvements in the same upstream branch.

flareofghast commented 9 years ago

I thought that is what I am doing. I made a fork, made my changes then created a PR. I have also noticed on your package.json you spelled your name wrong ;)

flareofghast commented 9 years ago

Why don't you use passport, passport-local and node-etc-passwd? Then you use passport to handle the authentication and session, in the local strategy just get the user and check the encoded password against the shadow password.

hexparrot commented 9 years ago

I would have already implemented passport-local, if they offered a working code example that was for a modern version of Expressjs. https://github.com/jaredhanson/passport-local/tree/master/examples

Expressjs is at 4.x; all samples are at 3.x