I am not sure to ask it here or at serverfault, but it has to do with my script and creating an installer...
I have made a service (linux perl script) and all the configuration files and etc etc.
I would like to make an installer for it so it creates folders/puts files on the right spot, etc.
Now while developing I made a script in the /etc/init.d/ folder called "reliand".
Now when I send all my files, plus the installer to another user and I would copy that file to the same dir on that machine (i know it's same CENTOS) how would I make it run at the right runlevel?
Do I need to make a link in the rd3.d folder? or is there a command to run so it will place itself in the correct runlevels.
Thanks for the explanation.
Use chkconfig --add and add something like:
# chkconfig: 345 20 80
# description: my service
to your script in /etc/init.d
Oh ... and https://serverfault.com/ is definitely a better place for this question.
Related
We have a directory /home/test/abc
Sometimes we found that the directory is not present. Most probably it is deleted by someone. We have lots of users who log in and out from the system.
I have checked the bash_history of all the users but nobody seems to have executed the rm command.
I would like to know if there is a way to monitor this directory and notify if a user or a script is trying to modify this directory.
I am using Centos
You can do two things:
You can install a utility that called acct (psacct), to monitoring on the user's activity on your machine.
You can install a tool that called inotify-tool, and after that, run the command: sudo inotifywait -m <your_file_path_here>, and it will monitor on your file activity in LIVE.
I just found Matlab (2016a) put a 2.5 Gb installation files that it fetched during the installation in the root home directory (Linux mint 18), under /root/Downloads/MathWorks. I guess it is probably because I use sudo for installation.
My question is:
Is it normal that program store information when user executes it with sudo?
Can I delete the file under /root/Downloads? (My limited Linux knowledge told me do not touch anything in the /root folder)
When you execute anything with su...do, you basically execute it 'as' root.
Mathworks uses the Download-Folder (which is in your case /root/Downloads - since you have executed the installer as root) for temporary data (According to https://de.mathworks.com/matlabcentral/answers/229835-is-the-mathworks-folder-necessary-to-run-properly?requestedDomain=www.mathworks.com).
So, yes. It seems like you can delete the folder.
Or just move it to MathWorks.bak and check if Mathworks still works properly. In case everything is working fine, you can delete MathWorks.bak.
A program can do anything when run as sudo and depends only on what the program is designed to do. sudo simply elevates the permissions when running a given command.
I would have thought that the installer would have downloaded everything to /tmp instead of /root/Downloads, but as long as you didn't select /root/Downloads as your installation directory for MATLAB and this is only the temporary download location you can certainly remove it after successfully installing MATLAB to a "typical" location such as /usr/local/MATLAB/R2016a.
I have created quite a few deb files, i have no problems doing that and they all run beautifully. However, if i want to replace a file in users home directory I am unsure on how to do that.
I have tried making a postinst to rsync the files from a predefined location to home directory, but since the postinst file is being run as root ( due to the debian installer running as root ) it is being sent to the root home directory and not the user's home directory....
Here's an example of the deb file contents :
Debian Directory ---> Control File ----> Postint File
usr/share/desktop (directory with files inside)
The postinst file has the sync command to send those files to users home:
#!/bin/sh
rsync -av /usr/share/desktop/ ~/.config/desktop/
The problem is it is sending the files to Root/home... not the default users home :(
I don't have the username of the user since this will be used on many computers with different users, therefore I can't use sudo -u username.
So what do I do? how do i replace files in users home directory from deb install? Any help is much appreciated.
In a Bash script, ~ refers to the current user's home directory. The package installation scripts are always run as root, so that's what "current user" means in this context.
(You could argue that the package installation is probably initiated by a user running su or sudo, but in the general case, you cannot assume this to be the case.)
Modifying user files from a system package appears extremely suspicious in any event. If the need is genuine, this should probably not be approached as a system package installation question in the first place. What are you actually trying to accomplish?
Not only are you violating the basic principle that package management should not meddle with user files; a consequence of this arrangement is that the operation can only be performed once: If the user has installed the package, attempting to install it again does nothing (at least until you uninstall).
A more manageable and predictable approach would seem to be making the package provide this functionality, but leave it to the user to invoke the actual sync (overwriting) script as needed. Perhaps you want to hook it into the desktop startup scripts somehow.
Having said that, sudo exposes the invoking user's identity in $SUDO_USER so you could look for that, and simply fail if it is not set.
As an aside, package scripts should work with dash so you need to avoid bashisms - prefer $HOME over ~, for example.
I managed to find a workaround, although it is not exactly what I was looking for, but here is my solution, at least for now.
#!/bin/sh
#This will move the desktop settings to required folder.
szAnswer=$(zenity --entry --text "Enter your login username\nThis must be entered correctly\n" --entry-text "Enter name of profile to use:")
xfce4-terminal -e "sudo rsync -av /usr/share/Desktop/ /home/$szAnswer/.config/xfce4/"
exit 0
In other words, the user gets asked to enter his username, and the files get copied to that user's home directory. The advantage is that if he does have multiple users, it will use the correct user. The disadvantage is if he enters username wrong, even a spelling mistake, the install will fail.
But it does work, I have tested. If anyone has a better solution I eagerly await your suggestions.
I have an Ubuntu 14.04 LTS server running a few different programs under Supervisor. Many of the programs need to store sockets and other named pipes on the filesystem, and /run seems like the ideal choice for these types of files. Unfortunately, /run is tmpfs and removed on every reboot, and root privileges are needed to (re)create the directories that each program can write to.
I need a way to create a few subdirectories in /run and set the owner/mode to something that each program can work with, and do so on each reboot before Supervisor tries to start them. It does not look like Supervisor supports a mechanism to run pre-start commands before it starts a program.
Most other answers for this type of question suggest doing it in the init script, but that belongs to Supervisor's package and I do not want to mess with it (or have to maintain it when it changes upstream).
If this machine had Systemd it seems like I could use /etc/tmpfiles.d, but it does not.
The best idea I came up with was to use a separate Upstart pre-start script for each program that only creates the directories without actually launching any processes. Something like:
/etc/init/myapp1.conf
start on runlevel [2345]
pre-start script
mkdir -p -m 0755 /var/run/myapp1
chown app1user: /var/run/myapp1
end script
...without any exec line. I'm not 100% sure this is valid or sane, but it appears to work. Are there cleaner ways to do something like this?
Do you run your apps under supervisor under a specific user? Because by default applications are run with root as owner.
What I would do is a simple script which does the following:
Checks if the required files/folders are created.
Sets the owner if necessary.
Then starts your application
Put this script into your supervisor config instead of directly starting your application. Make sure that it is run with root (remove user from the config or set user=root).
This way you can always make sure that your environment is set up and your directories exist. So if you clear the tempfs for some reasons, your scripts will still run without reboot.
If you NEED to run your applications under a specific user, you can do the following:
Move the first 2 points into a separate setup script (as you would do now using your solution).
Create another script which calls your setup script with sudo and starts your application
Add your custom user and script to the sudo file so that your user can call that script as root without a password prompt. (Be aware: this is a security risk, if someone gets access to your server. Make sure that your setup script is NOT writable)
I am installing gitlab on a mac but this latter is mainly designed for linux os. Following the doc, I have to run this command
curl --output /etc/init.d/gitlab https://raw.github.com/gitlabhq/gitlab-recipes/master/init.d/gitlab
What is the mac equivalent of the /etc/init.d folder (I know about the launchd command but I am looking for the mac's equivalent /etc/init.d folder) ?
AFAIK, launchd stores its data primarily in .plist files in /Library/LaunchAgents/ and /Library/LaunchDaemons/, and occasionally in those subdirectories in your home directory. More on those files in this tutorial and this reference.
For your problem specifically, to set launchd up to run gitlab, try converting that init.d script to a .plist file with the links above.
I don't know if you still care about the question or not, but what ryan said is correct. And to directly answer your question, your curl command is trying to download a startup script and put it into your init.d directory. You don't have one, as you are on Mac OS X.
What you need to do is pop that init.d somewhere else that is permanent. Make sure it is chmod +x and test to see if it works manually. (ie. ./init.d)
If it does, you can create a .plist and pop it into /Library/LaunchDaemons/ that will run your init.d file. If your init.d file is as simple as just running an executable, then forget the init.d file entirely, and just have the .plist file run the gitlab executable file directly.
Either way, I think that you should mark Ryan's (or mine as well) answer as Accepted, as it will solve your issue. The only reason I didn't put this as a comment on Ryan's answer is that my explanation was too long for a comment.
For a system with M1, it is stored in /sbin/launchd
It is differentiated with the PID 1