make command not found

[BogusCurry]

Hi ;) I am not know, is a bug, but I have download all files over git and install the required programms. When I make sudo make install, then comes make command not found ?

Can anyone help ?

Greetings Bogus

[Roflicide]

Hi Bogus, Thanks for downloading MSCS! I'm sorry you've been having issues, but fortunately the error you described is quite easy to fix:

You need to navigate to the downloaded directory prior to running sudo make install.

If you are unsure where you downloaded it, run the following command:

find / -type d -name MinecraftServerControlScript

This command will output the location of where you downloaded it. Then, simply navigate to the directory by typing

cd PATH

where PATH is the location of the downloaded directory. Once you're in this directory, you should be able to now run sudo make install.

If you're still having any further issues, please ask us and we'll be happy to help. :)

Best, Michael

[sandain]

You need to cd into the folder that you downloaded. It will contain a file called Makefile which the make command looks for, along with the mscs and msctl scripts, and a few other files.

[BogusCurry]

HI you both ;D Thanks for your fast answer, yes I have make the command in the download folder of mcms. I have make a picture, so I think better you see my problem I hope so ;D

Greetings Bogus

[Roflicide]

Hi again,

Do you have the make package installed? Please check if you have installed it by running the command

sudo apt-get install build-essential

Thanks, Michael

[BogusCurry]

ok that was, thanks for you support ;D

Greetings and have a nice day ;D

[Roflicide]

No problem! if you have any other issues, please feel free to submit another issue report.

[kicker22004]

Go figure, I've been building a bash based set of scripts to automate our server and then I find this.... Oh well. I really like some of the features here tho. I'm currently looking for a way to list all versions of MC server jars able to be downloaded. Can you give me any pointers? Great work here. Mine isn't as fully featured but I went more GUI based for new users to small systems (odroid,RPI,cubox,hummingbird) and of course it can run on full machines.

[zanix]

We download the list of available clients and server jars directly from Mojang. The URL is specified in the script here https://github.com/sandain/MinecraftServerControlScript/blob/master/msctl#L232

[zanix]

Oh lovely, there is a nice message in there that says this URL is going away.

"__comment": "This URL is being phased out! Please update your scripts to check https://launchermeta.mojang.com/mc/game/version_manifest.json instead. Thanks <3 --Dinnerbone",

Guess I should make a new issue for this.

[zanix]

but I went more GUI based for new users to small systems (odroid,RPI,cubox,hummingbird) and of course it can run on full machines.

This script is designed that it could be driven from a GUI, someone just needs to make one.

[kicker22004]

Yeah I seen that message about it going away. You could make your scripts use whiptail like I'm doing... Simple and nice. Thanks for the info.

[zanix]

Yes, but that would make the GUI debian only. Currently the script runs on more than just debian.

[kicker22004]

Ahh makes since.

[Roflicide]

@zanix

This script is designed that it could be driven from a GUI, someone just needs to make one.

In what way? In research I tried to do on creating GUI's out of bash scripts the GUI's seem to be pretty limited.

• Zenity is probably the most popular one I found, however it only works on Linux/Gnome systems; won't work for Unix or for those connecting via a SSH console to run the script (like myself; see this for source). Plus, the GUI capabilities of Zenity are pretty basic dialog messages from what I've seen. So I ruled this out.
• There's dialog and previously mentioned whiptail, but they're not really a true GUI since it's in-shell. More like paint splatters on a screen that resemble rectangles. Also, like you said it's debian only. Again, ruled this out.
• I was thinking a potential way of doing it would be to write, say, a GUI in java that executes the script and reads in the output from the script. However I think this is a bad idea since it's very dependent on the output and if that were to change in future versions it would screw up the GUI. So I crossed this option off too.

So, in the conclusion I reached anyway, I think the only way to actually produce a nice, clean looking GUI that could function across all UNIX/Linux systems and with SSH would be to rewrite the script into another scripting language like Python, Perl etc... which isn't a very viable option, lol.

@sandain @zanix What do you guys think, do you agree with my reasoning? Or did I miss something in my evaluation? (I probably did given my extremely limited programming knowledge...)

[zanix]

I never heard of Zenity. Whiptail is debian only, dialog is a bit more common but possibly not as useful.

At one time we were thinking of something web based, like python or php that would call the script and parse it's output. That way the cli and gui would be separate and users could choose just cli or both.

You are correct, the cleanest way would be to rewrite this is another language that you could tie into a GUI via either desktop or web.

I think MSCS is kept as minimal as possible to run on as many systems as possible with minimal requirements.

[sandain]

I haven't really given much thought to tacking a GUI onto the script. It would be very doable, for the most part I try to minimize user facing changes -- they do happen, but for good reasons I hope.

Java would work well. Early on, I had thought about doing a html based interface, but never got around to it because I never spent the time to examine the security implications.

With Java, you would need to do some trickery with a ssh tunnel to be able to remote control the script from a Windows box, but that is doable. The html interface that I had originally given thought to could run from the same machine without any trickery.

Either way, I imagine the gui could run multiple instances of the script at the same time to say run a Query to fill a data window and open a console in another window. I haven't tested this idea though.

[kicker22004]

Yeah I'd say stay just minimum, I run Debian based usually so built around whiptail. If you want web based just go MineOS. But I like minimum that's why I started with bash and whiptail.

[Roflicide]

@zanix

At one time we were thinking of something web based, like python or php that would call the script and parse it's output. That way the cli and gui would be separate and users could choose just cli or both.

So, when you say parse the output you mean run commands, read the output, and create a GUI based on the output of the commands right? Is this how people generally create GUI's layered on top of console commands?

I think MSCS is kept as minimal as possible to run on as many systems as possible with minimal requirements.

That makes sense.

@sandain

I haven't really given much thought to tacking a GUI onto the script. It would be very doable, for the most part I try to minimize user facing changes -- they do happen, but for good reasons I hope.

Yea, I agree with this, I was just playing around with ideas for making the GUI as a feature that could perhaps simplify the console commands, mostly for other admins on my server who aren't comfortable using the console.

Java would work well. Early on, I had thought about doing a html based interface, but never got around to it because I never spent the time to examine the security implications.

So, just to clarify for my own sake, we could tackle this with two approaches: web-based or client based. Web-based is less secure because you have to send data over the internet, right? Whereas client-based (Java) would be more secure because you run it locally on your computer?

With Java, you would need to do some trickery with a ssh tunnel to be able to remote control the script from a Windows box, but that is doable.

Why is that? Couldn't you login through SSH, then run a command to start up a java application and shouldn't it behave normally? Or are you talking about creating a Java application that incorporates an SSH login, and is that what you mean by having to do some trickery with the tunneling?

Also, on a similar note, couldn't you make the web/html/php GUI secure by having it run on localhost after authenticating with SSH? Or do I have it all wrong

[sandain]

So, when you say parse the output you mean run commands, read the output, and create a GUI based on the output of the commands right? Is this how people generally create GUI's layered on top of console commands?

It is a common model.

So, just to clarify for my own sake, we could tackle this with two approaches: web-based or client based. Web-based is less secure because you have to send data over the internet, right? Whereas client-based (Java) would be more secure because you run it locally on your computer?

I think security concerns are common with both models. How much do you trust the users of your gui? If you allow for your users to provide text based input, you either have to trust them completely or you have to trust that your user input sanitation step is doing its job.

If you trust your users, using a ssh tunnel or web authentication can help ensure your users are who they say they are. Regardless, it might be a good idea to think about adding in a user input sanitation step.

Why is that? Couldn't you login through SSH, then run a command to start up a java application and shouldn't it behave normally? Or are you talking about creating a Java application that incorporates an SSH login, and is that what you mean by having to do some trickery with the tunneling?

If you are using X forwarding, sure. However, I don't know of many Windows users able to handle X. A better method would be to have the Java app establish a ssh tunnel to send commands to the server with the script and listen for a response. Or simply run a Web based app from the same server and use web based authentication.

Also, on a similar note, couldn't you make the web/html/php GUI secure by having it run on localhost after authenticating with SSH? Or do I have it all wrong

You could with X forwarding. See above.

[kicker22004]

Either way you handle this, It would make it all too bulky for smaller machines. Sorry I think about the little home/personal machines that people will use that aren't always up to the work load of Minecraft or the added weight of an X server to have a full GUI. This is just the way I think. I think the scripts are perfect the way it is and should be left as such. For my project it's only for debian based Os and whiptail uses no extra power to do simple tasks anyways.

On Wed, Feb 17, 2016 at 6:52 PM, Jason M. Wood notifications@github.com wrote:

So, when you say parse the output you mean run commands, read the output, and create a GUI based on the output of the commands right? Is this how people generally create GUI's layered on top of console commands?

It is a common model.

So, just to clarify for my own sake, we could tackle this with two approaches: web-based or client based. Web-based is less secure because you have to send data over the internet, right? Whereas client-based (Java) would be more secure because you run it locally on your computer?

I think security concerns are common with both models. How much do you trust the users of your gui? If you allow for your users to provide text based input, you either have to trust them completely or you have to trust that your user input sanitation step is doing its job.

If you trust your users, using a ssh tunnel or web authentication can help ensure your users are who they say they are. Regardless, it might be a good idea to think about adding in a user input sanitation step.

Why is that? Couldn't you login through SSH, then run a command to start up a java application and shouldn't it behave normally? Or are you talking about creating a Java application that incorporates an SSH login, and is that what you mean by having to do some trickery with the tunneling?

If you are using X forwarding, sure. However, I don't know of many Windows users able to handle X. A better method would be to have the Java app establish a ssh tunnel to send commands to the server with the script and listen for a response.

Also, on a similar note, couldn't you make the web/html/php GUI secure by having it run on localhost after authenticating with SSH? Or do I have it all wrong

You could with X forwarding. See above.

— Reply to this email directly or view it on GitHub https://github.com/sandain/MinecraftServerControlScript/issues/113#issuecomment-185518962 .

[zanix]

I think if a GUI layer was made, it would be an optional addition to the CLI

[sandain]

If we were to write a GUI, it would be an optional component to the CLI like @zanix mentioned. My goal all along has been to keep this script as light weight as possible.

[Roflicide]

@sandain thanks for taking the time to answer the multitude of question I had =) I'm gonna pelt a few more at ya', if you don't mind...

However, I don't know of many Windows users able to handle X

What do you mean not being able to handle? After doing some research, it looks as if setting up X forwarding on Windows isn't very hard in itself; it's mostly installing a program called XMing and using it in tandem with the SSH client that the person already has (must likely PuTTY). That seems to be it. Though, I would understand if you wouldn't want the GUI to depend on XMing for fellow SSH users as it is an additional program they have to install.

How much do you trust the users of your gui?

Hmmm, this is an interesting question. You're definitely right when you say that you need authentication. I had to do some research on the whole "user sanitization" of forms and such, and from the information I gleaned I came to understood it as preventing accidental/malicious output of data which could be sensitive, right? One website listed this xkcd comic which pretty much sums up my understanding, lol

So, I guess it is the best practice to have both authentication & user-sanitation (like you said).

Initially I wasn't even thinking of the GUI as having fields where you wouldn't input text--just buttons and dropdowns, to keep it nice and simple--it wouldn't have all the features of the script.

Here's a mockup I made of an idea for it, tell me what you think.

Overall, I imagine it as something that would be used for more of monitoring the servers, rather than actually configuring it. I probably would also want to include something on memory usage below the server information panel, too.

Whether it should be html/php based or java based, im not sure; the little programming knowledge I have, I know some Java, so I'd be more comfortable with that.

[sandain]

Let's move this discussion over to a new issue: #118