I have a problem. Depending on the plattform my files in the rpm have different users/groups.
The problem is you already shoud see the right attributes of the rpm with rpm -V so I can't change the Attributes in the %post section because this will always show the user has been changed.
Is there a way to create a global variable where I set the name of the variable user and then use it in the %files section?
I tried it with define but it does not work right:
%pre
HOME = path
if[true]
%define USER example1
useradd -m -r -c $HOME $USER
else
%define USER example2
useradd -m -r -c $HOME $USER
fi
%files
%defattr(-, %{USER}, ...)
This gives me the error warning: user example2 does not exist - using root
Does anyone know how to solve this problem?
%files is evaluated and installed before %post is executed. The user must exist in advance. Therefore:
At very top of spec file puth
%global USERNAME example1
%global GROUPNAME example1
and then in %pre put:
%pre
getent group %{GROUPNAME} >/dev/null || groupadd -r %{GROUPNAME}
getent passwd %{USERNAME} >/dev/null || \
useradd -r -g %{GROUPNAME} -d HOMEDIR -s /sbin/nologin \
-c "Useful comment about the purpose of this account" %{USERNAME}
exit 0
For more information see:
https://fedoraproject.org/wiki/Packaging:UsersAndGroups?rd=Packaging/UsersAndGroups#Dynamic_allocation
I pretty sure that this is not best practice but I found a way:
%build
if [condition]; then
%global USERNAME example1
else
%global USERNAME example2
fi
And later in the %pre section I can add the user, in case he does not exists.
Then I can use this variable user in the files section just as in my question with %attr(-, %{USERNAME}, ...)
If I would define the global variable at the beginning of the file
(%global USERNAME example0), the build would simply use the value defined there and ignore the changed values in the %build.
Related
When using WP CLI in docker, I need to execute it as root.
I need to add the flag --allow-root directly in .bashrc and I am trying to figure out why it doesn't work.
FROM webdevops/php-dev:7.3
# configure postfix to use mailhog
RUN postconf -e "relayhost = mail:1025"
# install wp cli
RUN curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar && \
chmod +x wp-cli.phar && \
mv wp-cli.phar /usr/local/bin/wp && \
echo 'wp() {' >> ~/.bashrc && \
echo '/usr/local/bin/wp "$#" --allow-root' >> ~/.bashrc && \
echo '}' >> ~/.bashrc
WORKDIR /var/www/html/
my .bashrc
# ~/.bashrc: executed by bash(1) for non-login shells.
# Note: PS1 and umask are already set in /etc/profile. You should not
# need this unless you want different defaults for root.
# PS1='${debian_chroot:+($debian_chroot)}\h:\w\$ '
# umask 022
# You may uncomment the following lines if you want `ls' to be colorized:
# export LS_OPTIONS='--color=auto'
# eval "`dircolors`"
# alias ls='ls $LS_OPTIONS'
# alias ll='ls $LS_OPTIONS -l'
# alias l='ls $LS_OPTIONS -lA'
#
# Some more alias to avoid making mistakes:
# alias rm='rm -i'
# alias cp='cp -i'
# alias mv='mv -i'
wp() {
/usr/local/bin/wp "$#" --allow-root
}
when I try to execute any wp command I get this error:
Error: YIKES! It looks like you're running this as root. You probably meant to run this as the user that your WordPress installation exists under.
If you REALLY mean to run this as root, we won't stop you, but just bear in mind that any code on this site will then have full control of your server, making it quite DANGEROUS.
If you'd like to continue as root, please run this again, adding this flag: --allow-root
If you'd like to run it as the user that this site is under, you can run the following to become the respective user:
sudo -u USER -i -- wp <command>
It looks like that command line doesn't consider what I input into .bashrc
Guys, do you have any suggestion how to fix this problem?
You are struggling with the classic conundrum: What goes in bashrc and what in bash_profile and which one is loaded when?
The extreme short version is:
$HOME/.bash_profile: read at login shells. Should always source $HOME/.bashrc. Should only contain environmental variables that can be passed on to other functions.
$HOME/.bashrc: read only for interactive shells that are not login
(eg. opening a terminal in X). Should only contain aliases and functions
How does this help the OP?
The OP executes the following line:
$ sudo -u USER -i -- wp <command>
The flag -i of the sudo-command initiates a login-shell
-i, --login: Run the shell specified by the target user's password database entry as a login shell. This means that login-specific resource files such as .profile, .bash_profile or .login will be read by the shell. If a command is specified, it is passed to the shell for execution via the shell's -c option. If no command is specified, an interactive shell is executed.
So the OP initiates a login-shell which only reads the .bash_profile. The way to solve the problem is now to source the .bashrc file in there as is strongly recommended.
# .bash_profile
if [ -n "$BASH" ] && [ -r ~/.bashrc ]; then
. ~/.bashrc
fi
more info on dot-files:
http://mywiki.wooledge.org/DotFiles
man bash
What's the difference between .bashrc, .bash_profile, and .environment?
About .bash_profile, .bashrc, and where should alias be written in?
related posts:
Run nvm (bash function) via sudo
Can I run a command loaded from .bashrc with sudo?
I recently had the same problem. In my Dockerfile, I was running:
RUN wp core download && wp plugin install woocommerce --activate --allow-root
I looked at the error message, and thought that from the way it was worded, the --allow-root gets ignored the first time you use it. So I added it to the first wp command, and It worked.
RUN wp core download --allow-root && wp plugin install woocommerce --activate --allow-root
The problem is that ~/.bashrc is not being sourced. It will only be sourced in an interactive Bash shell.
You might get better results doing it via executables. Something like this:
# install wp cli
RUN curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar && \
chmod +x wp-cli.phar && \
mv wp-cli.phar /usr/local/bin/wp-cli.phar && \
echo '#!/bin/sh' >> /usr/local/bin/wp && \
echo 'wp-cli.phar "$#" --allow-root' >> /usr/local/bin/wp && \
chmod +x /usr/local/bin/wp
/Users/ello/.zshrc:source:3: no such file or directory:
/Users/ello/Projects/config/env.sh
Ello-MacBook-Pro% /Users/ello/.zshrc:source
zsh: no such file or directory: /Users/ello/.zshrc:source
Ello-MacBook-Pro% /Users/ello/.zshrc
zsh: permission denied: /Users/ello/.zshrc
Ello-MacBook-Pro%
This has been happening, after I foolishly edited the .zshrc file. All that remains in the file now, after attempting to reset the shell, is this:
# Created by newuser for 5.3.1
# Add env.sh
How do I undo everything, reinstall zsh, or remake the .zshrc file?
This is on macOS Sierra.
Edit: I reinstalled oh-my-zsh, leading to this message:
ain() {
# Use colors, but only if connected to a terminal, and that terminal
# supports them.
if which tput >/dev/null 2>&1; then
ncolors=$(tput colors)
fi
if [ -t 1 ] && [ -n "$ncolors" ] && [ "$ncolors" -ge 8 ]; then
RED="$(tput setaf 1)"
GREEN="$(tput setaf 2)"
YELLOW="$(tput setaf 3)"
BLUE="$(tput setaf 4)"
BOLD="$(tput bold)"
NORMAL="$(tput sgr0)"
else
RED=""
GREEN=""
YELLOW=""
BLUE=""
BOLD=""
NORMAL=""
fi
# Only enable exit-on-error after the non-critical colorization
stuff,
# which may fail on systems lacking tput or terminfo
set -e
CHECK_ZSH_INSTALLED=$(grep /zsh$ /etc/shells | wc -l)
if [ ! $CHECK_ZSH_INSTALLED -ge 1 ]; then
printf "${YELLOW}Zsh is not installed!${NORMAL} Please install zsh
first!\n"
exit
fi
unset CHECK_ZSH_INSTALLED
if [ ! -n "$ZSH" ]; then
ZSH=~/.oh-my-zsh
fi
if [ -d "$ZSH" ]; then
printf "${YELLOW}You already have Oh My Zsh installed.${NORMAL}\n"
printf "You'll need to remove $ZSH if you want to re-install.\n"
exit
fi
# Prevent the cloned repository from having insecure permissions.
Failing to do
# so causes compinit() calls to fail with "command not found:
compdef" errors
# for users with insecure umasks (e.g., "002", allowing group
writability). Note
# that this will be ignored under Cygwin by default, as Windows ACLs
take
# precedence over umasks except for filesystems mounted with option
"noacl".
umask g-w,o-w
printf "${BLUE}Cloning Oh My Zsh...${NORMAL}\n"
hash git >/dev/null 2>&1 || {
echo "Error: git is not installed"
exit 1
}
# The Windows (MSYS) Git is not compatible with normal use on cygwin
if [ "$OSTYPE" = cygwin ]; then
if git --version | grep msysgit > /dev/null; then
echo "Error: Windows/MSYS Git is not supported on Cygwin"
echo "Error: Make sure the Cygwin git package is installed and is
first on the path"
exit 1
fi
fi
env git clone --depth=1 https://github.com/robbyrussell/oh-my-zsh.git
$ZSH || {
printf "Error: git clone of oh-my-zsh repo failed\n"
exit 1
}
printf "${BLUE}Looking for an existing zsh config...${NORMAL}\n"
if [ -f ~/.zshrc ] || [ -h ~/.zshrc ]; then
printf "${YELLOW}Found ~/.zshrc.${NORMAL} ${GREEN}Backing up to
~/.zshrc.pre-oh-my-zsh${NORMAL}\n";
mv ~/.zshrc ~/.zshrc.pre-oh-my-zsh;
fi
zsh itself does not have a default user configuration. So the default ~/.zshrc is actually no ~/.zshrc.
But as you tagged the question with oh-my-zsh I would assume that you want to restore the default oh-my-zsh configuration. For this it should be sufficient to copy templates/zshrc.zsh-template from your oh-my-zsh installation path, usually ~/.oh-my-zsh:
cp ~/.oh-my-zsh/templates/zshrc.zsh-template ~/.zshrc
You may want to backup your current ~/.zshrc beforehand. Although it may have some problems now, you still might want to look up some settings once you reverted to default.
There is no such thing as "default". The best you can do, is check if your system has /etc/skel/.zshrc. If yes copy that into your home.
When you log in first time, your home is populated with everything from /etc/skel.
My dumass decided to just put a crash command into the zsh file. Now when I open the terminal, it just kernel panics. so I just deleted the config file using rm -f ~/.zshrc* and by default, it just got replaced with another copy. So good luck.
You can copy .zshrc template from
https://github.com/ohmyzsh/ohmyzsh/blob/master/templates/zshrc.zsh-template
And copy and paste all content in to ~/.zshrc
[MS Windows Friendly Solution - If terminal(using vim editor) steps are confusing]
Actually, there is no default .zshrc file, but if you need to edit is as a simple notepad, do these:
Goto /Users/ Folder via Finder App.
Click Shift + Command + . (Dot) to view hidden system files.
Look on .zshrc file, double click to open, then it will open in a notepad(TextEdit.app) in default.
Clear whichever lines to be removed.
Retype/Edit the file as per the Paths to be added.
Hit Command + s to save and exit.
Make it your default shell using this command:
chsh -s $(which zsh)
Just installed tmux via homebrew and I'm trying to locate the system-wide tmux configuration file. The man pages state that the system-wide file should be located in /etc/tmux.conf, but for some reason, it is not there. Where is the default tmux.conf file located?
Note: Currently running OSX Mavericks
As far as I can tell the tmux installed via homebrew does not have a system wide conf file. If you did need one you could add your own at /etc/tmux.conf. However, I would wonder the need for this. I place my config in ~/.tmux.conf and everything is very happy.
There is a /usr/local/Cellar/tmux/1.8/etc directory but it houses the bash completion scripts. I also checked usr/local/etc it it to did not have an installed config.
I'm pretty confident at this point that the tmux installer via homebrew does not install it's own system wide config file instead leaving that as an exercise for the sys admin if such a feature was required.
By default tmux doesn't have a system-wide config that is editable. It's complied into the program.
Use these commands to list out the compiled defaults, then make your own file with it for your user.
tmux list-keys # show current bindings
tmux show-options -s # show current server options
tmux show-options -g # show current global session options
tmux show-options # show current session options
tmux show-options -gw # show current global window options
tmux show-options -w # show current window options
With tmux 1.7, show-options can also show you the value of a single option (prior versions can only list all the options from the specified class):
tmux show-options -gw window-status-format
You should find something useful in:
/usr/share/doc/tmux/examples
recent versions of tmux only have the examples conf files, it's not an OSX issue, just new default tmux packaging. So you can use any of those doing something like:
$cp /usr/share/doc/tmux/examples/someconffile.conf ~/.tmux.conf
that should do it.
from the man tmux page:
-f file Specify an alternative configuration file. By default, tmux loads the system configuration file from /usr/local/etc/tmux.conf, if present, then looks for a user configuration file at
~/.tmux.conf.
If there is no file, you can just create one using touch ~/.tmux.conf and write whatever you want.
Alon Gouldman's answer worked for me. Just to add to it:
I had this issue when working on Ubuntu 20.04.
Here's how I solved it:
Firstly, if do not find any configuratio file for tmux in your home directory, then create one inside your home (~) directory using the command:
touch ~/.tmux.conf
Next, to make the file to be always available whenever you start a Tmux session add the file to either the ~/.bash_profile, ~/.bash_login, and ~/.profile file. It should be added at the bottom of the file:
source "$HOME/.tmux.conf"
Here's an example:
# ~/.profile: executed by the command interpreter for login shells.
# This file is not read by bash(1), if ~/.bash_profile or ~/.bash_login
# exists.
# see /usr/share/doc/bash/examples/startup-files for examples.
# the files are located in the bash-doc package.
# the default umask is set in /etc/profile; for setting the umask
# for ssh logins, install and configure the libpam-umask package.
#umask 022
# if running bash
if [ -n "$BASH_VERSION" ]; then
# include .bashrc if it exists
if [ -f "$HOME/.bashrc" ]; then
. "$HOME/.bashrc"
fi
fi
# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
PATH="$HOME/bin:$PATH"
fi
# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/.local/bin" ] ; then
PATH="$HOME/.local/bin:$PATH"
fi
source "$HOME/.tmux.conf"
Note: The ~/.bash_profile file takes the first precedence, then the ~/.bash_login file as the second precedence, and then the ~/.profile file as the last precedence.
That's all.
I hope this helps
"I will take a crack at it. Here are some solutions off the top of my head. I do not run Mac but I run RH, Debian, FreeBSD, and Solaris, CYgwin and other stuff.
My understanding which is taken straight from man tmux. The -f flag will specify an alternative configuration file. By default, tmux loads the system configuration file from /etc/tmux.conf, if present, then looks for a user configuration file at ~/.tmux.conf. The configuration file is a set of tmux commands which are executed in sequence when the server is first started.
#!/usr/bin/env bash
unset temporary_array_tmp ; declare -a temporary_array_tmp
temporary_array_tmp=(/etc/tmux.conf ~/.tmux.conf)
# The next line creates an empty global and personal configuration file,
# if it individually does NOT exists.
for i_tmp in "${temporary_array_tmp[#]}" ; do
[[ ! -f "${i_tmp}" ]] && \
touch "${i_tmp}" && \
echo -en "I created an empty tmux configuration file # ${i_tmp}. " && \
echo -e "You need to add configuration settings to ${i_tmp} ." || \
echo -e "The tmux configuration file ${i_tmp} already exists."
done
# After you add configuration settings, then you need
# to tell tmux to reload the files.
for i_tmp in "${temporary_array_tmp[#]}" ; do
[[ -f "${i_tmp}" ]] && \
tmux source-file "${i_tmp}" && \
echo -e "${i_tmp} The tmux configuration file ${i_tmp} is loaded." || \
echo -e "The tmux configuration file ${i_tmp} is NOT loaded."
done
unset temporary_array_tmp
Mentionable Notes
Next you can find tmux directories and/or files using find. For example:
find ~/ /etc /usr -iname *tmux*
I'm currently working on a script that logs into another user account using
su username -c "comand1; comand2"
There's no sudo command in the shell.
However the environment variables do not change.
For example, the work directories are different with different users. So when the user is switched in the script, I expect that the $HOME variable should contain different work directories.
Does anyone know how to solve this problem?
You are probably looking for the -l (or just -) option to make it a login shell. See the manual for su(1).
One hack-ish kind of way would be put all env variables of the second user in a file (like .bashrc) and source it first in the list of the commands:
su username -c "source file_name; comand1; comand2"
There are two issues:
First: If you user " to delimit the argument for -c then everything in this argument is expanded by the calling shell and not by the executed shell. You can use ' instead of " to prevent this.
Second: By default su does not perform the same steps as during a real user login. Use the -l or - options. This may be required in your case or not - just try it.
Together:
> echo $HOME
/root
> su -c "echo $HOME" user -l
/root
> su -c 'echo $HOME' user -l
/home/user
> su -c 'echo $HOME' user
/home/user
Question would be
what exactly is the difference between running these two commands.
As a root, I have made a custom env. variable
export A="abcdef"
then in root shell
sudo -i
echo $A
returns
abcdef (as expected)
However, when I go back to normal user and run
sudo -i echo $A
it returns blank line.
So when you run command sudo echo $A, does it use environment variables and shell from the normal user?
and is there a way to get abcdef even if I run sudo echo $A ?
Thanks
EDIT 1
When you say you have made a variable A as root, I assume you mean you did this in root's .profile or something like that. --> (yes!)
EDIT 2
This makes perfect sense
but having some trouble.
When I do
sudo -i 'echo $A'
I get
-bash: echo $A: command not found.
However when I do
su -c 'echo $A'
it gives back
abcdef
What is wrong with the
sudo -i 'echo $A'
command?
If you want to pass your environment to sudo, use sudo -E:
-E The -E (preserve environment) option indicates to the
security policy that the user wishes to preserve their
existing environment variables. The security policy may
return an error if the -E option is specified and the user
does not have permission to preserve the environment.
The environment is preserved both interactively and through whatever you run from the command line.
When you say you have made a variable A as root, I assume you mean you did this in root's .profile or something like that. And I assume you mean that the normal user does not have A set. In that case the following applies:
When you run your command sudo -i echo $A this is first interpreted by the local shell and $A is substituted. That results in sudo -i echo, which is what is actually executed.
What you mean is this:
sudo -i 'echo $A'
That passes echo $A to the sudo shell.
~ rnapier$ sudo -i echo $USER
rnapier
~ rnapier$ sudo -i 'echo $USER'
root
Try this syntax:
sudo -i echo '$USER'
Although I couldn't replicate the results on my machine, the man page for sudo, specifies the -i option will unset/remove a handful of variables.
man sudo
-i [command]
The -i (simulate initial login) option runs the shell specified in the
passwd(5) entry of the target user as a login shell. This means that
login-specific resource files such as .profile or .login will be read
by the shell. If a command is specified, it is passed to the shell for
execution. Otherwise, an interactive shell is executed. sudo attempts
to change to that user's home directory before running the shell. It
also initializes the environment, leaving DISPLAY and TERM unchanged,
setting HOME , MAIL , SHELL , USER , LOGNAME , and PATH , as well as
the contents of /etc/environment on Linux and AIX systems. All other
environment variables are removed.
So I would try without the -i option.