launchctl - remove enabled/disabled override - osx-yosemite

On OS X Yosemite (10.10), is there any way to remove the enabled/disabled override setting for a service?
For example, to permanently disable non-existent service 'test' for root, do this:
sudo launchctl disable user/0/test
Check that it has been added to the disabled list:
sudo launchctl print-disabled user/0
Result:
disabled services = {
"test" => true
}
login item associations = {
}
Now, how can I delete "test" from the disabled services list?
(I know I can enable it, but I just want to remove the entry entirely.)
Note:
If I reboot my computer, I see that the 'test' override has been added to a launchd disabled file:
sudo cat /var/db/com.apple.xpc.launchd/disabled.0.plist
Result:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>test</key>
<true/>
</dict>
</plist>
I have tried running this command to manually delete it from the .plist file:
sudo /usr/libexec/Plistbuddy /var/db/com.apple.xpc.launchd/disabled.0.plist -c Delete:test
This does delete it from the file, but it just comes back again when I reboot my computer. Any ideas?

It seems like the nature of the info that used to be in overrides.plist has changed..
According to launchctl's man page for the "legacy" load / unload sub-commands..
-w Overrides the Disabled key and sets it to false or true for the load and unload subcommands respectively. In previous versions, this option would modify the configuration file. Now the state of the Disabled key is stored elsewhere on- disk in a location that may not be directly manipulated by any process other than launchd.
I guess now... the info is stored in the /var/db/com.apple.xpc.launchddirectory.
The contents of mine contained several plists.
config
disabled.0.plist
disabled.200.plist
...
disabled.501.plist
...
disabled.migrated
loginitems.0.plist
...
loginitems.501.plist
...
In this case, the file names are referring to the different Users' id's (501 being mine, 0 being root). Changing the keys in these files (as root, obviously) SHOULD remove the corresponding overrides with dark-overlord launchd.
If not, try editing these same files while booted to recovery, or some other drive - so as you can mess with them whilst launchd is not running/relentlessly trying to be boss.

I was able to do this using Single User Mode. The steps are:
Shut down your computer.
On startup, enter single-user mode (Command + S).
From the command line, type /sbin/mount -uw /
Edit the appropriate /var/db/com.apple.xpc.launchd/disabled.*.plist file, removing disabled items, as desired.
Type exit.

I've just solved this kinda problem with LaunchControl on yosemite…
its a must have amazing little GUI for managing your daemons and agents on OSX.
It has a lot of features…
So just install it with cask
$ brew cask install launchcontrol
then find your service (under Use Agents or Global Daemons or whatever… ) in the list on the left.
Select it and in the main menu go to Job=>Override Disabled key=>Always False
Then reboot and check...
Should work!

The configuration-files/scripts used by 'launchctl' are located in:
# Location of the LaunchAgents which run under the user own name (and is logged in).
$ cd $HOME/Library/LaunchAgents
# Location for the Deamons for running jobs without logged in user.
$ cd /Library/LaunchDaemons
# Location for the LaunchAgents which run as root when the user is logged in.
$ cd /Library/LaunchAgents
The following quick-and-easy commands for the XML-scripts (ending on .plist) are (assuming you are in one of the above listed directories and you may need a sudo):
# Loads the specified configuration file.
# Jobs that are not on-demand will be started as soon as possible.
$ The -w option overrides the disabled setting.
# The -F option forces the loading and ignores the Disabled key.
$ launchctl load <script-name.plist>
# Unloads the specified configuration file from the current started session.
$ The -w option overrides the disabled setting.
# The -F option forces the loading and ignores the Disabled key.
$ launchctl unload <script-name.plist>
# Removes the specified configuration from the list and does not appear after rebooting
$ launchctl remove <script-name.plist>
See the man page for launchctl at https://ss64.com/osx/launchctl.html for details.

Related

Unable to SSH after enforcing SELinux?

I have modified ”SELINUX=enforcing“ in /etc/selinux/config.But after restarting the machine,I can't ssh to my machine.
Prompt that
/bin/bash: Permission denied
When you edited the SELINUX for the first time or when switching between different types of policy, you need to relabel the filesystem. The below steps will do the relabel process automatically as shown in the procedures:
Restart server
reboot
On the GRUB display, press “e” to start editing the selected menu item.
Perform a break at an early stage of the boot process by typing 「rd.break」 at the end of the line starting
with kernel=.
kernel=... UTF-8 rd.break
Once ready press CTRL+X to start the boot process.
Check write access on the /sysroot mount point. By default this mount point is mounted only with the read-only (ro) access
mount | grep sysroot
=/dev/mapper/rhel-root on /sysroot type xfs (ro,relatime,attr2,inode64,noquota)
Remount the sysroot directory with read & write access.
mount -o remount,rw /sysroot
mount | grep sysroot
=/dev/mapper/rhel-root on /sysroot type xfs (rw,relatime,attr2,inode64,noquota)
Enter chroot system
chroot /sysroot
(new prompt) sh-4.4#
Force file-system relabeling. Next time when you will reboot the system, it will relabel the filesystem for
SElinux automatically.This usually occurs when labeling a file system for SELinux for the first time, or when
switching between different types of policy, such as changing from the targeted to the strict policy.
touch /.autorelabel
Exit the chroot. Reboot the machine
exit
logout or reboot (it will take time)
Now you should be able to login with ssh.

Error while httpd restart

My httpd.conf file contains following configurations
SSLPassPhraseDialog builtin
#SSLPassPhraseDialog exec:/root/passphrase.sh
when the line containing automatic reading of Passphrase is commented it works fine.
But when i change it to
#SSLPassPhraseDialog builtin
SSLPassPhraseDialog exec:/root/passphrase.sh
it fails, just with a failed message.
contents of passphrase file
#!/bin/bash
echo "xyz123"
Check rights permissions of passphrase file.
Possible causes for this.
Some times users put the passphrase-script under /etc/httpd/conf.d
directory. Don't do that.
Some time that script need to have execute (chmod +x) permission.
May be /bin/bash doesn't work with the current Linux distro then you have to include /bin/sh.

Changing permissions of added file to a Docker volume

In the Docker best practices guide it states:
You are strongly encouraged to use VOLUME for any mutable and/or user-serviceable parts of your image.
And by looking at the source code for e.g. the cpuguy83/nagios image this can clearly be seen done, as everything from nagios to apache config directories are made available as volumes.
However, looking at the same image the apache service (and cgi-scripts for nagios) are run as the nagios user by default. So now I'm in a pickle, as I can't seem to figure how to add my own config files in order to e.g. define more hosts for nagios monitoring. I've tried:
FROM cpuguy83/nagios
ADD my_custom_config.cfg /opt/nagios/etc/conf.d/
RUN chown nagios: /opt/nagios/etc/conf.d/my_custom_config.cfg
CMD ["/opt/local/bin/start_nagios"]
I build as normal, and try to run it with docker run -d -p 8000:80 <image_hash>, however I get the following error:
Error: Cannot open config file '/opt/nagios/etc/conf.d/my_custom_config.cfg' for reading: Permission denied
And sure enough, the permissions in the folder looks like (whist the apache process runs as nagios):
# ls -l /opt/nagios/etc/conf.d/
-rw-rw---- 1 root root 861 Jan 5 13:43 my_custom_config.cfg
Now, this has been answered before (why doesn't chown work in Dockerfile), but no proper solution other than "change the original Dockerfile" has been proposed.
To be honest, I think there's some core concept here I haven't grasped (as I can't see the point of declaring config directories as VOLUME nor running services as anything other than root) - so provided a Dockerfile as above (which follows Docker best practices by adding multiple volumes) is the solution/problem:
To change NAGIOS_USER/APACHE_RUN_USER to 'root' and run everything as root?
To remove the VOLUME declarations in the Dockerfile for nagios?
Other approaches?
How would you extend the nagios dockerfile above with your own config file?
Since you are adding your own my_custom_config.cfg file directly into the container at build time just change the permissions of the my_custom_config.cfg file on your host machine and then build your image using docker build. The host machine permissions are copied into the container image.

How to trace where php5-fpm umask settings are coming from on ubuntu

I'd really appreciate any help in tracking down and diagnosing an umask issue on Ubuntu:
I'm running php5-fpm with Apache via proxy_fcgi. The process is running with a umask of 0022 (confirmed by having PHP send the results of umask() into a file [the result is '18' == 0022]). I'd like to change this to 0002, but can't track down where the umask is coming from.
Apache is set with umask 0002, and as a test, if I disable proxy_fcgi and run my test above, I get a file with u+g having rw access (and the file contents confirm the umask as '2' == 0002).
If I sudo -iu fpmuser and run umask the results are 0002.
System info:
PHP: 5.5.3-1ubuntu2.1
Apache: 2.4.6
Ubuntu: 13.10
PHP-PFM is listing using TCP ports (as Unix ports aren't yet working/support)
So far I've tried the following (each followed by a system restart and a retest):
adding umask 0002 to the start of /etc/init.d/php5-fpm
adding --umask 0002 into the start-stop-daemon calls in /etc/init.d/php5-fpm
adding umask 0002 to .profile in the home of the fpm user
Something is clearly adjusting the umask of the php-fpm process - so, how can I begin tracing what is forcing the umask 0022 onto the php-fpm process?
EDIT (1):
adjusting the system wide umask via /etc/login.defs (see How to set system wide umask?) affects the umask elsewhere (e.g. comannds via sudo now have a umask of 0002), but still php-fpm creates files with a umask of 0022. Note that I verified that session optional pam_umask.so was also present in /etc/pam.d/common-session-noninteractive and I tested umasks of 002 and 0002.
EDIT (2):
I have been able to replicate the issue using nginx and php5-fpm (using unix sockets set to listen mode '0666').
I would love to trace where the umask is coming from but I'd settle for some way to force it to what I want.
I should add that the first test was done on an Amazon Ubuntu 13.10 image. My tests in 'edit 2' where completed using a copy of the Ubuntu13.10 server ISO setup from scratch in a virtual machine. All installations were completed via apt-get rather than by downloading the source and building.
EDIT (3):
I have confirmed I can manipulate the umask manually by either of the following (verified by checking the permissions on the test file created):
a. In a shell, set a umask then run /usr/sbin/php-fpm from the shell
b. In a shell, run the following with whatever umask value I like:
start-stop-daemon --start --quiet --umask 0002 --pidfile /var/run/php5-fpm.pid --exec /usr/sbin/php5-fpm -- --daemonize --fpm-config /etc/php5/fpm/php-fpm.conf
However this exact same command in the /etc/init.d/php5-fpm file fails to adjust the umask when running sudo service php5-fpm stop; sudo service php5-fpm start or at reboot.
Not a solution for generically tracing where umask settings are coming from on ubuntu (the only way I've found so far is the good old hard work approach of replicating the issue, attempting to isolate it to a script or a function, then stepping back through each script/function that is called recursively) but a solution to the php5-fpm umask issue. I've found a lot of hits on google, stackoverflow, and elsewhere for the problem, but so far no solution. Hopefully this is useful for people.
Edit /etc/init/php-fpm.conf to include the line umask 0002 (or whatever umask you wish). My version of the file now looks like this:
# php5-fpm - The PHP FastCGI Process Manager
description "The PHP FastCGI Process Manager"
author "Ondřej Surý <ondrej#debian.org>"
start on runlevel [2345]
stop on runlevel [016]
### my edit - change umask setting
umask 0002
pre-start exec /usr/lib/php5/php5-fpm-checkconf
respawn
exec /usr/sbin/php5-fpm --nodaemonize --fpm-config /etc/php5/fpm/php-fpm.conf
Explanation
Having traced through the service command which launches php5-fpm at startup, it runs some checks (line 118 on my copy) for /etc/init/${SERVICE}.conf, along with verifying initctl is present and can report it's version. If these tests are passed then upstart is used which in the case of php5-fpm uses the /etc/init/php-fpm.conf file.
The ubuntu upstart site gives pretty clear instructions. In particular you can check out the upstart cookbook for the specifics you need.
As best I can work out that means that therefore the 'service' command was never actually running the start-stop-daemon … commands found in /etc/init.d/php5-fpm which is why my previous edits were having no effect. Instead it passes off to upstart (actually initctl) when you use something like service php5-fpm start, etc.
If you use systemd, in the /etc/systemd/system directory, create a new directory called php7.2-fpm.service.d. The name of this directory will vary depending on your distro and PHP version. Run systemctl list-units --type=service | grep --ignore-case php to find out what to call it. Inside of this directory, place a file called umask.conf with the contents:
# /etc/systemd/system/php7.2-fpm.service.d/umask.conf
[Service]
UMask=0002
For the changes to take effect, run:
systemctl daemon-reload && systemctl restart php7.2-fpm
The benefit of this solution is that your customizations are not lost when packages get updated.
Explanation of how this works from the systemd manual:
Along with a unit file foo.service, a "drop-in" directory foo.service.d/ may exist. All files with the suffix ".conf" from this directory will be parsed after the file itself is parsed. This is useful to alter or add configuration settings for a unit, without having to modify unit files. Each drop-in file must have appropriate section headers. Note that for instantiated units, this logic will first look for the instance ".d/" subdirectory and read its ".conf" files, followed by the template ".d/" subdirectory and the ".conf" files there.
In addition to /etc/systemd/system, the drop-in ".d" directories for system services can be placed in /usr/lib/systemd/system or /run/systemd/system directories. Drop-in files in /etc take precedence over those in /run which in turn take precedence over those in /usr/lib. Drop-in files under any of these directories take precedence over unit files wherever located. Multiple drop-in files with different names are applied in lexicographic order, regardless of which of the directories they reside in.
better copy systemd script before editing php5-fpm.service or it will be overwritten on next update:
cp /lib/systemd/system/php5-fpm.service /etc/systemd/system/
vi /etc/systemd/system/php5-fpm.service
Add: UMask=0002 in [Service] section.
systemctl daemon-reload
systemctl restart php5-fpm
Source: https://ispire.me/running-php-fpm-with-different-user-group-using-umask/
okey, but this applies to all the pools.
Would be handy to be able to set it with something like
env[umask] = 0002
(no chance for this to work)
been googling, but doesn't seem to be a way to do this on a per host basis.

The application cannot be opened because its executable is missing

I have an application that I have been developing for some time now. Recently launching the application via a double click presents a dialog that says "You can't open the application RepoWatch because it may be damaged or incomplete."
Launching the application via open ./RepoWatch.app gives me "The application cannot be opened because its executable is missing."
I usually launch the application via ./RepoWatch.app/Contents/MacOS/RepoWatch simply out of habit (which DOES work), so I am unsure how long this has been happening, or what change happened immediately before hand. The most likely change is that I put cp Info.plist ./RepoWatch.app/Contents/ into my make file in order to version Info.plist without versioning everything in the .app bundle.
I have looked at Info.plist many times and cannot find anything wrong with it. The file opens up with Property List Editor without any errors. Saving from Property List Editor does not make the file "work" (if it is to blame in the first place).
The permissions as far as I can tell also look sane:
$ ls -l
./RepoWatch.app/Contents/Info.plist
-rw-rw-r--# 1 dgrace staff 789 Feb 1 23:20 ./RepoWatch.app/Contents/Info.plist
$ ls -l
/Applications/Adium.app/Contents/Info.plist
-rw-rw-r-- 1 dgrace staff 5750 Aug 21 15:41 /Applications/Adium.app/Contents/Info.plist
I am at a loss as to what to try next.
And here are the contents of Info.plist (Even though nothing has really changed in quite a while):
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>CFBundleInfoDictionaryVersion</key>
<string>6.0</string>
<key>CFBundleDevelopmentRegion</key>
<string>English</string>
<key>CFBundleExecutable</key>
<string>RepoWatch</string>
<key>CFBundleIdentifier</key>
<string>com.doomstick.RepoWatch</string>
<key>CFBundleName</key>
<string>RepoWatch</string>
<key>CFBundleShortVersionString</key>
<string>1.0.0</string>
<key>LSMinimumSystemVersion</key>
<string>10.6</string>
<key>CFBundleVersion</key>
<string>Beta26</string>
<key>NSMainNibFile</key>
<string>MainMenu</string>
<key>NSPrincipalClass</key>
<string>NSApplication</string>
</dict>
</plist>
Building on the answer that #smokris posted:
The problem seems to be with your app's registration in the Launch Services database. There is no need to rebuild the entire database. To force-update the entry for your app (specifically), use lsregister with the -f option:
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -f MyApp.app
I was having the same problem you describe, and this worked for me. Thanks, #smokris!
Rebuilding the Launch Services database solves this problem for me.
Try executing the following command in Terminal:
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -kill -r -domain local -domain system -domain user
The problem is likely due to an invalid CFBundleExecutable property value in the Info.plist file you are copying into the application.
In Xcode projects the default value for this property is a special variable (placeholder) value (${EXECUTABLE_NAME}) that is expanded (replaced) when the build system builds the application. Are you sure you need to copy this file manually? Maybe you can add a script build phase that makes whatever changes you need after it has been expanded and copied into place by the normal build process.
While you are at it, you should check for other placeholder values in the file. It is likely that you will need to fill in CFBundleName (others may also be necessary, depending on your application type).
OK, some (more) shots in the dark.
The docs for LSMinimumSystemVersion say that the value is supposed to be a string with the form n.n.n. You might try adding a “.0” to the end of your value.
When you use ./RepoWatch.app/Contents/MacOS/RepoWatch to run it manually, are you using some sort of completion or filename generation, or are you typing it all in (especially the filename of the executable)?
Maybe the executable filename has some odd invisible/combining/look-alike character in it that does not match the value in Info.plist. Try ls -w /path/to/RepoWatch.app/Contents/MacOS/ | xxd to look at the bytes for anything non-ASCII.
Does plutil -lint /path/to/Info.plist give you an “OK”?
The # after the permissions in the ls -l output indicates some xattrs. These could be harmless, but have you looked at which ones are there with ls -l#?
If one of the xattrs looks suspect (or even if not) you could (cd /path/to/RepoWatch.app/Contents/ && mv Info.plist Info.plist.save && cat Info.plist.save > Info.plist) to get a copy without the xattrs and test with it.
If using the non-xattr'd file still causes problems, you might try systematically modifying and deleting keys (after making a backup copy, like the .save above) to see if you can cause a different error message that might help indicate the problem.
Project Menu > Set Active Executable