How to add user for Jetty 7 in windows OS - linux

I am learning how to use Jetty 7 for the first time.
I followed the steps in this tutorial:
https://wiki.apache.org/solr/SolrJetty
The website is presenting the steps using Linux command (I believe). However I am using windows 7, and I am stuck at the Create User portion.
Creating user
Don't forget to create solr user in the system.
useradd -d /opt/solr -s /sbin/false solr
chown solr:solr -R /opt/solr
chown solr:solr -R /var/log/solr # if you use alternative folder for logs
NOTE: If you don't have start-stop-daemon tool you have to setup /bin/bash instead /sbin/false.
So my question is how do I do this in Windows?

a very good way is to use yajsw. This will allow you to install Solr as a service in windows, and also in unix/linux, as it is cross platform. So if you learn how to use it in one OS it will be very similar in others.
I have used it many times in linux/windows.

Related

Dedicated CoreNLP Server Control Issues

Question: How can I confirm whether or not my "Dedicated Server" is running properly?
Background: I am working to get a 'Dedicated CoreNLP Server' running on a stand-alone Linux system. This system is a laptop running CentOS 7. This OS was chosen because the directions for a Dedicated CoreNLP Server specifically state that they apply to CentOS.
I have followed the directions for the Dedicated CoreNLP Server step-by-step (outlined below):
Downloaded CoreNLP 3.7.0 from the Stanford CoreNLP website (not GitHub) and placed/extracted it into the /opt/corenlp folder.
Installed authbind and created a user called 'nlp' with super user privileges and bind it to port 80
sudo mkdir -p /etc/authbind/byport/
sudo touch /etc/authbind/byport/80
sudo chown nlp:nlp /etc/authbind/byport/80
sudo chmod 600 /etc/authbind/byport/80
Copy the startup script from the source jar at path edu/stanford/nlp/pipeline/demo/corenlp to /etc/init.d/corenlp
Give executable permissions to the startup script: sudo chmod a+x /etc/init.d/corenlp
Link the script to /etc/rc.d/: ln -s /etc/init.d/corenlp /etc/rc.d/rc2.d/S75corenlp
Completing these steps is supposed to allow me to run the command sudo service corenlp start in order to run the dedicated server. When I run this command in the terminal I get the output "CoreNLP server started" which IS consistent with the the start up script "corenlp". I then run the start command again and get this same response, which is NOT consistent with the start up script. From what I can tell, if the server is actually running and I try to start it again I should get the message "CoreNLP server is already running!" This leads me to believe that my server is not actually functioning as it is intended to.
Is this command properly starting the server? How can I tell?
Since the "proper" command was not functioning as I thought it should, I used the command sudo systemctl *start* corenlp.service and checked the service's status with sudo systemctl *status* corenlp.service. I am not sure if this is an appropriate way in which to start and stop a 'Dedicated CoreNLP Server' but I can control the service. I just do not know if I am actually starting and stopping my dedicated server.
Can I use systemctl command to operate my Dedicated CoreNLP Server?
Please read the comments below the originally posted question. This was the back and forth between #GaborAngeli and myself which lead my question/problem being solved.
The two critical steps I took in order to get my instantiation of the CoreNLP server running locally on my machine after following all the directions on how to setup a dedicated server, which are outlined on Stanford CoreNLP's webpage, are as follows:
Made two modifications to the "corenlp" start-up script. (1) added sudo to the beginning because the user "nlp" needs permissions to certain files on the system (2) changed the first folder path from /usr/local/bin/authbind to /usr/bin/authbind. authbind installation must've changed since the start up script was written.
nohup su "$SERVER_USER" -c "sudo /usr/bin/authbind --deep java -Djava.net.preferIPv4Stack=true -Djava.io.tmpdir_"$CORENLP_DIR" -cp "$CLASSPATH" -mx15g edu.stanford.nlp.pipeline.StanfordCoreNLPServer -port 80"
If you were to attempt to start the server with the change above you would not successfully run server because sudo usage requires a password input. In order to allow sudo privileges without a required password entry you need to edit the sudoers file (I did this under the root user b/c you need permissions to change or even view this document). my sudoers file was located in /etc. There is a part that says ## Allows people in group wheel to run all commands and below that is a section that says ##Same thing without a password. You just need to remove the comment mark (#) form in front of the next line which says %wheel ALL+(ALL) NOPASSWD: ALL. Save this file. BE CAREFUL IN EDITING THIS FILE AS IT MAY CAUSE SERIOUS ISSUES. MAKE ONLY THE NECESSARY CHANGE OUTLINED ABOVE
Those two steps allowed me to successfully run my dedicated server. My system runs on CentOS 7.
HELPFUL TIP: From my discussion with #GaborAngeli I learned that within the 'corenlp' folder (/opt/corenlp if you followed the directions correctly) you can open the stderr.log file to help you in trouble shooting your server. This outputs what you would see if you were to run the server in the command window. If there is an error it is output here too, which is extremely helpful.

Run executable file from a different user

While creating an rpm spec file I have created a new user and group in the %pre section. This new user does not however have permission to login from from shell for security purposes. Now when I install the rpm this new user is successfully created. However, I wish to start the installed rpm service with the newly created user. Currently I simply write; 'filePath/file.exe file.cfg' to execute the file.exe with its configuration file i.e. file.cfg in my 'init.d' file to start the service. How can I modify this command to start the same service but with the user that I created while installing the rpm? Basically I want to execute the program in my init.d file but through a different user, like I would have done with sudo if my required user was the super user. Any feedback will be highly appreciated.
Your initial starting point both for installing the rpm and for running the service is privileged. For instance, on my CentOS 6 machine, I see in /etc/passwd
games:x:12:100:games:/usr/games:/sbin/nologin
but running as root, I can do this:
$ sudo -u games /bin/sh
sh-4.1$ echo $PATH
/sbin:/bin:/usr/sbin:/usr/bin
sh-4.1$ id
uid=12(games) gid=100(users) groups=100(users) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
sh-4.1$ cd
sh-4.1$ pwd
/usr/games
In your service script, you can use sudo to run a given process as another user (though a quick check of the same machine does not show this being done).
#msuchy points out that runuser may be preferable. I see that this is relatively recent (according to Ubuntu runuser command?, appeared in util-linux 2.23 -- lacking a date makes release notes less than useful...). The oblique comments in its documentation about PAM make it sound as if this circumvents some of the security checks. Perhaps someone has a better comment about that.

Is there a way to 'store' Sudo temporarily

I'm quite new to Linux. I remember using a tutorial were you were able to declare your sudo (+password) at the start and then use terminal without having to do sudo or import your password again.
I.e.
Sudo yum-get update -> yum-get update.
Sorry if this is a very obvious question, I honestly don't remember where the tutorial was from, and how to do it again.
ps - if it helps, I'm on a RedHat Distro, but go between Debian and RedHat.
You can use su. This way you are changing the ownership of the session to root (by default, you can also change to any other user on the system) and therefore you will be able to avoid the sudo.
Here you can find some more information on the command.
You may use
sudo -i
It acquires the root user's environment and kind of simulates a login into the root account

Why running sudo to my own account fixes graphical problems in Swing GUI

My swing GUI application starts with a script.
When I run that script under Linux without sudo it gives me unexpected Look and feel and other graphical problems.
Why is running with sudo su to my own account fixes this problem?
One might guess that the program is trying to make use of a file that has permissions that allow root to access it, but not your uid. Perhaps you have a library installed with wrong permissions?
strace will tell you what files your app is trying to access.

Best way elevate the privileges programmatically under different versions of Linux?

There is a standard way (working across Linux distributions) to launch a process (from another application) asking for the root password in order to elevate privileges?
I tried to use gksudo (it is installed in ubuntu by default), but under other distributions (or under other desktop manager) it may not be installed.
I would recommend looking at PolicyKit which is what most modern distros are using to accomplish this.
That works everywhere but does not cache the password and asks for the root and not the user password (as sudo does):
su - -c command
EDIT: Not on ubuntu where the root-account is disabled. Probably you need something like that:
test -x /usr/bin/sudo && sudo command || su - -c command
The only default thing is text mode su. Most distros have also sudo installed.
Now, in KDE based distros you'll have kdesu, while in GNOME based it'll be gksu and gksudo. Machines in Kerberized domains have ksu.
You might try to use /etc/sysconfig/desktop to see which is the default desktop.
Traditionally, if your application needs to allow a user to elevate privileges, it installs its own single-purpose setuid executable -- single-purpose meaning that it performs the task needed, instead of acting as a general-purpose launcher.
$ su -
# cp `type -p id` /usr/local/bin/root-id
# chown root:users /usr/local/bin/root-id
# chmod 4750 /usr/local/bin/root-id
$ /usr/local/bin/root-id
... euid=0(root) ...
OTOH setuid executables have also been a common source of security holes too, so exercise care.

Resources