What is the proper way to build Wine in 64bit Debian? - linux

Q) What is the proper way to build Wine in 64bit Debian? What is the modern tool chain and how must it be implemented to complete the task? And also.. how do I incorporate Wine Nine into the package?
People have been asking for years and even when the available tutorials are up to date they are incomplete, so only complete answers on this thread please!

A) I will attempt my own answer. Feel free to recycle bits of it as part of an improved or more modern answer! This was originally meant for 17.1 but with the 17.3 changes added after. It's all from sporadic notes/term output so there is definitely room for better answers here. In fact I think I lost a piece somewhere! Hope this helps fellow Debian lovers anyways! Best of luck! This will definitely ruin your weekend and end in abject failure, so at least there is that to look forward to!
Building Wine in Debian > 9
1) Setting up the Environment:
# Start by grabing some development tools and basic dependencies:
sudo apt-get install debhelper apt-utils binutils-multiarch-dev gcc-multilib pkg-config libtool-bin python-mako build-essential devscripts git git-buildpackage
sudo dpkg --add-architecture i386
sudo apt-get build-dep mesa
sudo apt-get build-dep wine
# And you could make git pretty like that one guy does, which debian probably did already:
git config --global color.ui auto
git config --global core.whitespace trailing-space,space-before-tab
# From: https://wiki.debian.org/PbuilderTricks https://wiki.ubuntu.com/PbuilderHowto
# http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.building.html
# Essentially we need to build some libraries then build against those libraries. Even with a true multiarch process in hand we'd be at the mercy of debian packaging, and DFSG policy is not for the faint of heart. At first gbp may seem like yet another tool but infact git-buildpackage is a wrapper that makes dealing with it all easier and solves that irritating little chroot problem for us. Mostly.
# First lets prep our 32bit chroot a bit:
ARCH=i386 git-pbuilder create
ARCH=i386 git-pbuilder login --save-after-login
# We need to build wine against mesa, so we start a private repo for when we've built it:
apt-get install nano apt-utils
nano /etc/apt/sources.list
# Example
deb http://mirrors.accretive-networks.net/debian/ sid main contrib
deb-src http://mirrors.accretive-networks.net/debian/ sid main contrib
# apt-ftparchive:
deb [trusted=yes] file:///home/user/pbuilder/deps ./
apt-get update
apt-get upgrade
apt-get dist-upgrade
# If it wasn't sid it is now. Oh yeah, dependencies:
sudo apt-get build-dep mesa
sudo apt-get build-dep wine
exit
# Now create that directory!
mkdir -p /home/user/pbuilder/deps
# You can do the same with amd64 but realy we only need it for wine64.. it simplifies cross building the wow64 stuff:
ARCH=amd64 git-pbuilder create
# Optional, just saves redownloading if your first build fails:
ARCH=amd64 git-pbuilder login --save-after-login
sudo apt-get build-dep wine
exit
# Install the private repo with a script, so you don't have to log in and do it by hand in the future (even more optional):
sudo mkdir -p /var/cache/pbuilder/hook.d
mkdir -p /home/doc/pbuilder/deps
# This doesn't work on drives using nodev, add 'dev' to defaults or remove for drives /etc/fstab entry
# Somebody should do something about that.
bash -c 'cat > /etc/pbuilderrc << EOF
# the file in /usr/share/pbuilder/pbuilderrc is the default template.
# /etc/pbuilderrc is the one meant for overwriting defaults read pbuilderrc.5
MIRRORSITE=http://mirrors.accretive-networks.net/debian/
OTHERMIRROR="deb [trusted=yes] file:///home/user/pbuilder/deps ./"
BINDMOUNTS="/home/user/pbuilder/deps"
# the hook dir may already be set/populated!
HOOKDIR="/var/cache/pbuilder/hook.d"
# this is necessary for running 'apt-ftp-archive' in the hook below
EXTRAPACKAGES="apt-utils"
EOF'
bash -c 'cat > /var/cache/pbuilder/hook.d/D01mesa << EOF
#!/bin/bash
# https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788580
# This fix didnt seem to work for test sys: mount -t devpts none /dev/pts
# Added dev to defaults on / and /opt in /etc/fstab, this is potentially a security issue but should be fine temporarily.
# Private Repo
(cd /home/user/pbuilder/deps; apt-ftparchive packages . > Packages)
# Add deps:
apt-get update
#apt-get install -f libegl1-mesa:i386=17.1.5-1 etc, etc,
#apt --fix-broken install
EOF'
# Create the empty list:
touch /home/user/pbuilder/deps/Packages
# updates chroots sources.list
sudo pbuilder --update --override-config --distribution sid
chmod u+x /home/user/pbuilder/D01deps
# The tutorial shows the actual editing of the appropriate debian/ directory. We supply those for the tutorial versions.
# If your version debian/ is older than source, you will need to remove the debian/patches it comes with.
# (i.e wget urltosome.deb; dpkg -x some.deb /some/where)
# We assume you will have them ready in /opt/src/debian-mesa and -wine/ so no git is provided here:
# Lets establish /opt/src as our working directory and populate our gits
mkdir -p /opt/src; cd /opt/src
# old: git clone http://copr-dist-git.fedorainfracloud.org/git/kkofler/qtwebengine/mesa.git mesa.nlp/
git clone git://anongit.freedesktop.org/mesa/mesa mesa.git/
git clone git://source.winehq.org/git/wine.git wine.git/
git clone --depth=1 https://github.com/wine-compholio/wine-staging.git wine-staging/
git clone --depth=1 https://github.com/sarnex/wine-d3d9-patches wine-d3d9/
# Go ahead and skip this bit if you plan to go straight to the Mesa 32bit build:
git clone --depth=1 git://anongit.freedesktop.org/mesa/drm libdrm/
git clone --depth=1 git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
# So thats most the downloading finished anyways!
2) Proper Kernel Config
# This next bit mostly from: https://people.freedesktop.org/~mslusarz/nouveau-wiki-dump/InstallDRM.html
# This kernel worked on the test system, but was not with out issues. Kernel config needs it own tutorial the minimum for nouveau is shown here:
cd /opt/src/linux-2.6
apt-get install xorg-dev kernel-package
# For nouveau:
git remote add nouveau git://anongit.freedesktop.org/nouveau/linux-2.6
git remote update
git checkout -b nouveau-master nouveau/master
# Otherwise -b master
# Ok to just hit enter for all the new stuff...
cp -i /boot/config-`uname -r` ./.config
make oldconfig
# ... because we are looking closer now
make xconfig # needs libqt4-dev or use menuconfig and libncurses5
# Nouveau sanity checks:
#scripts/config --enable CONFIG_FB
scripts/config --enable CONFIG_I2C
scripts/config --enable CONFIG_I2C_ALGOBIT
scripts/config --enable CONFIG_FRAMEBUFFER_CONSOLE
scripts/config --enable CONFIG_BACKLIGHT_LCD_SUPPORT
scripts/config --enable CONFIG_BACKLIGHT_CLASS_DEVICE
scripts/config --enable CONFIG_FB_CFB_FILLRECT
scripts/config --enable CONFIG_FB_CFB_COPYAREA
scripts/config --enable CONFIG_FB_CFB_IMAGEBLIT
scripts/config --enable CONFIG_VT_HW_CONSOLE_BINDING
# Avoid the following framebuffers: offb uvesafb nvidiafb rivafb nvidia
cat .config | grep NVIDIA
# (Outdated) If you need firmware:
# Download file from https://people.freedesktop.org/~pq/nouveau-drm/
# Or follow steps at https://people.freedesktop.org/~mslusarz/nouveau-wiki-dump/NVC0_Firmware.html
# Place in /lib/usr/nouveau
git merge origin
# The fun bit..
search "<<<" keep origin:
#sudo nano drivers/gpu/drm/nouveau/nouveau_fence.c
# OR
git checkout origin drivers/gpu/drm/nouveau/nouveau_fence.c
git add .
git commit
git merge origin
make-kpkg clean
fakeroot make-kpkg --initrd --revision=1.0.custom kernel_image
# To later update gits:
git remote update
git reset --hard nouveau/master
# Libdrm, for reference:
autoreconf -vfi
./configure --prefix=/usr/ --disable-intel --disable-vmwgfx --disable-radeon --enable-omap-experimental-api --enable-install-test-programs
sudo cp src/.libs/nouveau_drv.so /usr/lib/xorg/modules/drivers
3) Build Mesa:
cd /opt/src/mesa.git
git checkout -b master origin/master
cp ../debian-mesa/ debian/ -R
# You can skip these edits if your using debian/ from tutorial or use your and edit:
echo "10" > debian/compat
# Be sure to use tabs not spaces and stay to format in:
nano debian/rules
# You should replace all gallium-llvm with -llvm, but it's not entirely needed.
# find: confflags += \
# add: --enable-nine \
# replace: --disable-omx \
# with: --disable-omx-bellagio \
# replace: dh_install -a --fail-missing
# with: dh_install -a
echo "17.3.0" > VERSION
# You can follow the examples inside, or use dch -i instead:
nano debian/changelog
# echo "NOT_INSTALLED :=" > debian/not-installed # ?
# We need to install st nine somewhere, it may as well be here:
sudo bash -c 'cat > debian/libgl1-mesa-glx.install << EOF
usr/lib/*/d3d/d3dadapter9.so
usr/lib/*/d3d/d3dadapter9.so.*
usr/lib/*/pkgconfig/d3d.pc
usr/include/d3dadapter/drm.h
usr/include/d3dadapter/d3dadapter9.h
usr/include/d3dadapter/present.h
EOF'
# There will be symbol changes, if your lucky, my diff will get you by.
# If not, your first build will fail and generate it's own diff, use that like so:
sudo bash -c 'cat > debian/patches/gbm-addsymbols.diff << EOF
--- debian/libgbm1.symbols (libgbm1_17.3.0_i386)
+++ dpkg-gensymbols4b6R6J 2017-09-18 09:07:51.531786647 +0000
## -3,6 +3,7 ##
gbm_bo_create#Base 7.11~1
gbm_bo_create_with_modifiers#Base 17.1.0~rc2
gbm_bo_destroy#Base 7.11~1
+ gbm_bo_get_bpp#Base 17.3.0
gbm_bo_get_device#Base 8.1~0
gbm_bo_get_fd#Base 10.2~0
gbm_bo_get_format#Base 8.1~0
## -25,6 +26,7 ##
gbm_device_destroy#Base 7.11~1
gbm_device_get_backend_name#Base 7.11~1
gbm_device_get_fd#Base 7.11~1
+ gbm_device_get_format_modifier_plane_count#Base 17.3.0
gbm_device_is_format_supported#Base 8.1~0
gbm_surface_create#Base 8.1~0
gbm_surface_create_with_modifiers#Base 17.1.0~rc2
EOF'
echo 'gbm-addsymbols.diff' >> debian/patches/series
git add .
git commit -a
ARCH=i386 gbp buildpackage --git-pbuilder --git-dist=sid --arch=i386 --git-force-create --git-upstream-tree=SLOPPY --git-no-pristine-tar --git-ignore-new
# Failed?
# should be same as git reset --hard, debian/rules clean will get ran anyways:
git clean -f -d -i -x
# <fix problem>
git add .
git commit -a
ARCH=i386 gbp buildpackage --git-pbuilder --git-dist=sid --git-arch=i386 --git-force-create --git-upstream-tree=SLOPPY --git-no-pristine-tar --git-ignore-new
# Success?
# Great! The 64bit build should now be trivial (and faster with out gbp):
git clean -f -d -i -x
debuild -us -uc -B
# Let's move the clutter:
mkdir /opt/debs; mv /opt/src/*.deb /opt/debs
# And put some i386 copies in our repo:
cp /opt/debs/*i386.deb /home/user/pbuilder/deps
# Go install them!
sudo dpkg -i /opt/debs/*.deb
sudo aptitude
# Resolve, repeat! Twice should do it!
### OLD:
# Pre 17.2 symbol changes:
debian/libgl1-mesa-glx.symbols
# Top:
d3dadapter9.so.1 libgl1-mesa-glx #MINVER#
D3DAdapter9GetProc#Base 17.1.8
libGL.so.1 libgl1-mesa-glx | libgl1
(arch=!hurd-any)MesaGLInteropGLXExportObject#Base 12.0.4
(arch=!hurd-any)MesaGLInteropGLXQueryDeviceInfo#Base 12.0.4
4) Build Wine Already!
# The generate.py package generator from winehq is less work to modify then the official packages, bit still needs changes for nine
git clone https://github.com/<tut> debian-mesa/
git clone https://github.com/<tut> debian-wine/
git clone https://github.com/wine-compholio/wine-staging.git wine-staging/
git clone https://github.com/wine-compholio/wine-packaging.git wine-packaging/
ARCH=i386 git-pbuilder create
git clone git://source.winehq.org/git/wine.git wine.git/
cd /opt/src/wine.git
# Find staging version and match it to the wine source:
/opt/src/wine-staging/patches/patchinstall.sh --upstream-commit
# Should be on branch master already, so stay there:
git reset --hard 0b1d7ff7655c5aa7ff073f67400bd4401727183f
# OR:
# git checkout -b <name> 0b1d7ff7655c5aa7ff073f67400bd4401727183f
# and use gbp --git-debian-branch=<name>
# Apply ixit patches:
mkdir d3d9; cp ../d3d9/*.patch d3d9/;
cp ../wine-staging/patches/ ./ -R
# Build the winehq packaging and place it:
/opt/src/wine-packaging/generate.py --out . debian-sid-staging
cp /opt/src/wine-packaging/debian-sid-staging/debian debain/ -R
## -1,3 +1,5 ##
+d3dadapter9.so.1 libgl1-mesa-glx #MINVER#
+ D3DAdapter9GetProc#Base 17.1.8
libGL.so.1 libgl1-mesa-glx | libgl1
(arch=!hurd-any)MesaGLInteropGLXExportObject#Base 12.0.4
(arch=!hurd-any)MesaGLInteropGLXQueryDeviceInfo#Base 12.0.4
# Use tabs in things like debian/rules.. you were warned!
nano debian/rules
#Find: "$(CURDIR)/patches/patchinstall.sh" DESTDIR="$(CURDIR)" --all
#Add: patch -p1 < "$(CURDIR)d3d9/staging-helper.patch
# patch -p1 < "$(CURDIR)d3d9/wine-d3d9.patch
# On both:
#Find: $(CONFFLAGS)
#Replace: $(CONFFLAGS) \
--enable-nine
ARCH=i386 gbp buildpackage --git-pbuilder --git-dist=sid --git-arch=i386 --git-force-create --git-upstream-tree=SLOPPY --git-no-pristine-tar --git-ignore-new
wine --check-libs
wine --patches
Good Luck! (You'll need it)

Related

Running bash script in another directory

I know this question has been asked many times before but I have not been able to get my code working.
I am using the Raspberry Pi 3, with a CAN-BUS Shield. As this will be going into a production environment I need the Pi setup to be nice and easy. I have started to write a bash script so the production staff can run the script and the Pi will update and install everything it needs from the one script.
I have been following this web site https://harrisonsand.com/can-on-the-raspberry-pi/ and I have run into a problem when it comes to compiling can-utils.
I am able to clone the can-utils.git from here https://github.com/linux-can/can-utils.git
by using sudo git clone https://github.com/linux-can/can-utils.git
but my issues come when I need to run the ./autogen.sh & the ./configure as these are located in the dir can-utils.
If I run this from the Pi terminal as described on the web site, it works fine as I change dir cd can-utils and then just sudo ./autogen.sh but it isn't working when I run it in the bash script.
Below is the script I have so far, I know that most of it is commented out this is so that I can test each part as I write it and don't need to constantly download and install stuff I already have
#!/bin/bash
## Change Password
#printf "***********************************************************************\n"
#printf "Changing Password\n"
#echo "pi:***********" | sudo chpasswd # Password hidden
#sleep 1
#printf "Password Changed\n"
## Update & Upgrade Pi
#printf "***********************************************************************\n"
#printf "Update & Upgrade Pi\n\n"
#sudo apt-get update && sudo apt-get upgrade -y
#sleep 1
## Upgrade dist
#printf "***********************************************************************\n"
#printf "Upgrade Dist\n\n"
#sudo apt-get dist-upgrade -y
#sleep 1
## Install libtools
#printf "***********************************************************************\n"
#printf "Installing libtools\n\n"
#sudo apt-get install git autoconf libtool -y
#sleep 1
## Download required files
#printf "***********************************************************************\n"
#printf "Downloading required files\n\n"
## can-utils
#sudo git clone https://github.com/linux-can/can-utils.git
#sleep 1
## Auto configure can-utils
printf "***********************************************************************\n"
printf "Auto Configure can-utils\n\n"
# Things I have tried and do not work
#(cd /c && exec /can-utils/autogen.sh)
#sudo source /can-utils/autogen.sh
#sudo ./can-utils.autogen.sh
sleep 1
When I try the sudo ./can-utils.autogen.shin the Pi terminal the script starts to work so I think this is sort of the right command I need but then I get an error autoreconf: 'configure.ac or 'configure.in' is required these files are in the can-utils dir but for some reason it can't find them. Please can someone help me I have been searching for the answer for the last 2 days
Thank you for your help, rightly or wrongly I have ended up using cd /home/pi/can-utils I had thought I had tried that in the past but I think cd ./can-utils which didn't work.
sudo with script is for me, a nightmare. I just read in the man of sudo of my fedora 25:
Running shell scripts via sudo can expose the same kernel bugs that make setuid shell scripts unsafe on some operating systems (if your OS has a /dev/fd/ directory, setuid shell scripts are generally safe).
sudo command should protect the root account to avoid to run scripts written by user to gain root privilege.
If you keep the use of sudo, my advise should to add a cd command on top of your script:
cd /where_everithing_is
to be sure to be in the right place.
But, may be, sudo will fight again against you !

Syntax error when running .sh script on linux. What am I doing wrong?

I've been attempting to write a shell script to detect composer and git on a virtual linux = Ubuntu 16.0.4 machine and then install them if needed. + clone the required repository if the machine is ready for it.
Now this is my first attempt to write any kind of script and also sorry if somehow I messed up the question itself, I'm quite now on stackoverflow as well.
Any help is appreciated, thanks in advance.
Here's the original task specification I received initially:
-check if git is installed on server
if so, clone repo with codebase
-check if composer is installed on server
if so, composer install in the root directory of the laravel application
-finally, php artisan migrate --seed
Now this is how I was trying to achieve this:
#!/bin/bash
echo "The installation process is about the begin..."
if ! which git;
then echo "Git has been located on the destination system. Cloning begins..."
git clone <link to the gitlabe repo>
else echo "There is no Git installed on the system. Git installation commences..."
sudo apt-get update
sudo apt-get upgrade
sudo apt-get install git
echo "Cloning begins..."
git clone <link to the gitlabe repo>
fi
if ! which composer;
then
echo "Composer has been located on the destination system."
else
echo "There is no Composer installed on the system. Composer installation commences..."
sudo apt-get update
sudo apt-get upgrade
sudo apt-get install composer
fi
sudo apt-get update
sudo apt-get install curl php5-cli git
curl -sS https://getcomposer.org/installer | sudo php -- --install- dir=/usr/local/bin --filename=composer
composer global require "laravel/installer"
sudo apt-get update
'Now the preferred version in the vagrantfile has to be edited to be 1.8.1 instead of 1.9'
'Generate a ssh key'
ssh-keygen -t rsa -b 4096 -C "< e-mail adress that I used >"
'Start ssh agent eval $'
ssh-agent -s
'Add your SSH private key to the ssh-agent'
ssh-add -K ~/.ssh/id_rsa
php artisan migrate --seed
The error message I recieve:
sudo sh ./testscript.sh
[sudo] password for linuxtest:
The installation process is about the begin...
: not foundt.sh: 3: ./testscript.sh:
: not foundt.sh: 4: ./testscript.sh:
: not foundt.sh: 5: ./testscript.sh:
./testscript.sh: 72: ./testscript.sh: Syntax error: end of file unexpected (expecting "then")
The answer that helped me solve my problem was posted by Charles Duffy in a comment:
This looks like your file has DOS rather than UNIX newlines. This will prevent syntax like fi from being recognized, because it's read as fi$'\r', which isn't a keyword.
#!/bin/bash
echo "The installation process is about the begin...";
if [ -x "$(command -v git)" ]; then
echo "Git has been located on the destination system. Cloning; begins..."
git clone <link to the gitlabe repo>;
else
echo "There is no Git installed on the system. Git installation commences...";
sudo apt-get update && sudo apt-get upgrade && sudo apt-get install git;
echo "Cloning begins...";
git clone <link to the gitlabe repo>;
fi
if [ -x "$(command -v composer)" ]; then
echo "Composer has been located on the destination system.";
else
echo "There is no Composer installed on the system. Composer installation commences...";
sudo apt-get update && sudo apt-get upgrade && sudo apt-get install composer;
fi
Hey there
I think this should fix your If condition problem. If you want to know more about how you should check for the case that a programm exists, look here:
Check if a program exists from a Bash script
Its the second answer for a quickfix.
Always remember to chain commands which are depending on the success of the preceding command via "&&". This secures that the next command will just be executed if the preceding doesn't fail.
I recommend doing it the same way with the ssh commands.
#edit
also make sure that you end each command with a semicolon.
hope I could help.

Explanation of this docker file?

I am trying to understand this docker file
FROM ubuntu:trusty
MAINTAINER Wurstmeister
RUN apt-get update; apt-get install -y unzip openjdk-7-jre-headless wget supervisor docker.io openssh-server
ENV JAVA_HOME /usr/lib/jvm/java-7-openjdk-amd64/
RUN echo 'root:wurstmeister' | chpasswd
RUN mkdir /var/run/sshd
RUN sed -i 's/PermitRootLogin without-password/PermitRootLogin yes/' /etc/ssh/sshd_config
EXPOSE 22
I understood most of the lines but I don't understand what these below lines means?
apt-get install -y unzip openjdk-7-jre-headless wget supervisor docker.io openssh-server
echo 'root:wurstmeister' | chpasswd
sed -i 's/PermitRootLogin without-password/PermitRootLogin yes/' /etc/ssh/sshd_config
Can anyone help me understand? I am not sure what is the purpose of wget supervisor docker.io openssh-server in that line. Also what does echo mean there? And then also last sed line.
apt-get install -y unzip openjdk-7-jre-headless wget supervisor docker.io openssh-server
Installs a bunch of packages using the ubuntu package manager (the base image is Ubuntu Trusty 14.04).
The -y option is used to prevent apt from asking user confirmation about installing the packages and their dependencies: the installation just proceeds without need for any input. This is needed to avoid hanging the process of building the docker image. Packages installed:
openssh-server: so that the container can act as an ssh server and process requests from ssh clients
wget, unzip: utilities
java: eventually this container is used to allow users to access it via ssh, maybe those users need java
supervisor, docker.io: I don't see a direct usage of it in the Dockerfile itself
then
echo 'root:wurstmeister' | chpasswd
Changes password of user root to wurstmeister
sed -i 's/PermitRootLogin without-password/PermitRootLogin yes/' /etc/ssh/sshd_config
Replaces the text PermitRootLogin without-password with PermitRootLogin yes in file /etc/ssh/sshd_config to allow root user to login with password or without (e.g., with public key).
An important general note: If you run SSHD in your Docker containers, you're doing it wrong!
wget supervisor docker.io openssh-server are parameters to the apt-get call. Those are the names of the packages to be installed.
echo is used in combination with | to send the new password to the chpasswd command.
sed is used to update some text in a configuration file (here to allow passwordless login). The s/text/newText/ part does text substitution.

How can I get a secure system-wide oh-my-zsh configuration?

I'd like to have a system-wide oh-my-zsh setup, but I'm not sure what would be the "best" approach for this. It is not my intention to ask about personal preferences or the like, I'm just unsure whether the solutions below are:
ln my local user configuration somewhere doesn't seem right, because adding an exploit to my local cfg and therefore gain root permissions would be very easy.
Installing oh-my-zsh to /etc would be maybe also a security hole because I simply haven't written it by myself.
Simply writing my own personal .zshrc would be the last approach I would like to try out because it’s very time-consuming.
Any recommendations?
Unless I'm misunderstanding the marked answer from Caleb is just the normal per-user installation steps with adding a .zshrc file to the skel dir and changing the default new-user shell, but it doesn't actually work or really answer the question because each user still requires the oh-my-zsh dir/would still require each user to clone the oh-my-zsh dir into their own folder meaning it's not really installed system wide, it just automatically gives them a zshrc file and changes the default shell to zsh, but without oh-my-zsh in each user folder it will error out.
From what I understand of the question it's asking how to install oh-my-zsh system-wide aka have it installed in ONE place and not require manually messing around on each new user/having a git clone of oh-my-zsh on each user dir. Assuming that's the case, here's what I did based off Arch Linux's AUR Package I normally use but was looking for the same on a centos server, however this can be done on any distro. Credit goes to MarcinWieczorek and the other maintainers, I just adapted the below so can do the same on non-arch distros.
If you already have oh-my-zsh installed on root just skip to Step 3. This isn't distro specific just uses the AUR Patch File for zshrc
Step #1
Install zsh of course
Step #2
Install oh-my-zsh as root as normal (shows wget method, see Calebs answer for alternative)
sh -c "$(wget https://raw.githubusercontent.com/robbyrussell/oh-my-zsh/master/tools/install.sh -O -)"
Step #3
Move the install to /usr/share so is system-wide
#Copy zsh files to /usr/share for all uer access
mv /root/.oh-my-zsh /usr/share/oh-my-zsh
# Move into the dir and copy the zshrc template to zshrc (which will be the default for users)
cd /usr/share/oh-my-zsh/
cp templates/zshrc.zsh-template zshrc
# Nab the patch file from MarcinWieczorek's AUR Package and apply to the zshrc file
wget https://aur.archlinux.org/cgit/aur.git/plain/0001-zshrc.patch\?h\=oh-my-zsh-git -O zshrc.patch && patch -p1 < zshrc.patch
Now oh-my-zsh is installed globally and the user just needs that zshrc file. so NOW is where Caleb's answer comes in though just do the below as /etc/adduser.conf is only on debian whereas the below should be distro independent.
Step #4
Set it up to be the default on new users
# Create hard link to the zshrc file so it creates an actual independent copy on new users
sudo ln /usr/share/oh-my-zsh/zshrc /etc/skel/.zshrc
# Set default shell to zsh
sudo adduser -D -s /bin/zsh
Now that's a true installation of oh-my-zsh with all new users automatically having it applied with the /usr/share/oh-my-zsh/zshrc settings and no other steps needed.
Misc Notes
For any pre-existing users with oh-my-zsh:
cp /usr/share/oh-my-zsh/zshrc ~/.zshrc
You can set new user OMZ defaults in /usr/share/oh-my-zsh/zshrc
Auto Updates are disabled since new users do not have permissions to update the /usr/share/oh-my-zsh files
To update oh-my-zsh just cd to /usr/share/oh-my-zsh/ and run 'sudo git pull'
The oh-my-zsh cache will be handled per-user within each user dir under ~/.oh-my-zsh-cache/ (automatically created)
Fair Warning: this assumes a Debian style linux, but this should work on other forms as well. This also assumes you are starting from scratch.
Part 1, the install:
You will need to install zsh system wide, and not just for one user. (you may have already done this but I'll include it just to be comprehensive)
make sure you have installed zsh, simply: sudo apt-get install zsh
Follow the oh-my-zsh install guide or you can either:
use curl
sh -c "$(curl -fsSL https://raw.githubusercontent.com/robbyrussell/oh-my-zsh/master/tools/install.sh)"
use wget
sh -c "$(wget https://raw.githubusercontent.com/robbyrussell/oh-my-zsh/master/tools/install.sh -O -)"
Part 2, Setting up zsh when new users are added:
You will need to make it so that new users default to zsh. In your /etc/adduser.conf file edit the line that says:
DSHELL=/bin/sh
to:
DSHELL=/bin/zsh
You should also change it for the /etc/default/useradd file, change the line:
SHELL=/bin/sh
to:
SHELL=/bin/zsh
Part 3, set your custom theme.
I have a custom theme file (here) that I wanted all users on the system to have. First, you should add the file to your .oh-my-zsh/themes folder:
cp your_custom_style.zsh-theme ~/.oh-my-zsh/themes
Next, edit your .zshrc file in your home directory, change the ZSH_THEME="default" to ZSH_THEME="your_custom_style"
Then, reload your .zshrc file with: . ~/.zshrc
Part 4, setting up new user's home directories.
We need to to place whatever files we want the new users to have in the /etc/skel directory, because this is what the system copies when it is creating new user's home directory. See this sys admin guide for details.
Copy your user's files (you may need to sudo):
cp -r .oh-my-zsh /etc/skel/
cp .zshrc /etc/skel
Now you will be able to add new users and they will have oh-my-zsh by
default with whatever custom theme you want them to have.
If you want to change all other existing user's shell to zsh, I would recommend reading this serverfault question.
If you want a system-wide install of Oh-My-Zsh, a convenient approach that overwrites the least number files is:
sudo git clone https://github.com/robbyrussell/oh-my-zsh.git /etc/oh-my-zsh
sudo cp /etc/oh-my-zsh/templates/zshrc.zsh-template /etc/skel/.zshrc
sudo mkdir -p /etc/skel/.oh-my-zsh/cache
Edit /etc/skel/.zshrc:
Edit the line export ZSH=$HOME/.oh-my-zsh (currently line 5)
Change the line to be:
export ZSH=/etc/oh-my-zsh
export ZSH_CACHE_DIR=~/.oh-my-zsh/cache
Then edit /etc/default/useradd and change the line SHELL=... to SHELL=/bin/zsh.
That's basically all (of course, git and zsh must be installed already).
To update a pre-existing user: login as them and cp /etc/skel/.zshrc ~/.zshrc
Update: Please do not edit this. I just rolled back an edit which completely botched it up!
Login as ROOT
Step 1: Install ZSH
# Download and extract ZSH
wget https://github.com/zsh-users/zsh/archive/zsh-5.8.tar.gz -P /tmp/demo/zsh
cd /tmp/demo/zsh
tar -xvzf zsh-*
cd zsh-zsh-5.8
# configure and make
sudo ./Util/preconfig
sudo ./configure
sudo make && sudo make install
# Add ZSH to the list of shells
echo /usr/local/bin/zsh | sudo tee -a /etc/shells
Step 2: Install oh-my-zsh
# If you're running the Oh My Zsh install script as part of an automated install,
# you can pass the flag --unattended to the install.sh script.
# This will have the effect of not trying to change the default shell, and also won't
# run zsh when the installation has finished.
sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)" "" --unattended
# Add oh-my-zsh to /usr/share
mv /root/.oh-my-zsh /usr/share
mv /usr/share/.oh-my-zsh /usr/share/oh-my-zsh
mv /root/.zshrc /usr/share/oh-my-zsh
mv /usr/share/oh-my-zsh/.zshrc /usr/share/oh-my-zsh/zshrc
# Modify zshrc to point to /usr/share/oh-my-zsh
sed -i 's|export ZSH="'"$HOME"'/.oh-my-zsh"|export ZSH="\/usr\/share\/oh-my-zsh"|g' /usr/share/oh-my-zsh/zshrc
Step 3: Add Extra (Optional - Look at the bottom for extra features)
Step 4: Create Symbolic link
# Create Symbolic Links to /etc/skel
sudo ln /usr/share/oh-my-zsh/zshrc /etc/skel/.zshrc
Step 5: Add oh-my-zsh for root
# Change shell to ZSH for root
echo "$USER" | chsh -s /usr/local/bin/zsh
Step 6: Add oh-my-zsh for user
# Change user
su - username
# Copy zshrc to $HOME for user
cp /usr/share/oh-my-zsh/zshrc ~/.zshrc
# Change shell to ZSH for user
echo "$USER" | chsh -s /usr/local/bin/zsh
OR
sudo -i -u username bash << EOF
cp /usr/share/oh-my-zsh/zshrc ~/.zshrc
echo username | chsh -s /usr/local/bin/zsh
EOF
EXTRA:
Change theme to powerlevel10k
git clone --depth=1 https://github.com/romkatv/powerlevel10k.git ${ZSH_CUSTOM:-/usr/share/oh-my-zsh/custom}/themes/powerlevel10k
sed -i 's/ZSH_THEME="robbyrussell"/ZSH_THEME="powerlevel10k\/powerlevel10k"/g' /usr/share/oh-my-zsh/zshrc
Enable Auto correction
sed -i 's/# ENABLE_CORRECTION="true"/ENABLE_CORRECTION="true"/g' /usr/share/oh-my-zsh/zshrc
Enable Auto suggestions and Syntax highlighting
git clone --depth=1 https://github.com/zsh-users/zsh-autosuggestions ${ZSH_CUSTOM:-/usr/share/oh-my-zsh/custom}/plugins/zsh-autosuggestions
git clone --depth=1 https://github.com/zsh-users/zsh-syntax-highlighting.git ${ZSH_CUSTOM:-/usr/share/oh-my-zsh/custom}/plugins/zsh-syntax-highlighting
sed -i 's/plugins=(git)/plugins=(\n git\n zsh-autosuggestions\n zsh-syntax-highlighting\n)/' /usr/share/oh-my-zsh/zshrc
sed -i 's/plugins=(git)/plugins=(git)\nZSH_DISABLE_COMPFIX=true/' /usr/share/oh-my-zsh/zshrc
Add nord dircolors
git clone --depth=1 https://github.com/arcticicestudio/nord-dircolors.git /tmp/demo/dircolors
mv /tmp/demo/dircolors/src/dir_colors /usr/share/
cd /usr/share/
mv /usr/share/dir_colors /usr/share/.dir_colors
tee -a /usr/share/oh-my-zsh/zshrc >/dev/null <<'EOF'
test -r "/usr/share/.dir_colors" && eval $(dircolors /usr/share/.dir_colors)
EOF
I combined cFINNY's answer, reading and understanding the oh-my-zsh install script, the AUR patch in his answer, and fixing the broken adduser command to do this install in a FROM ubuntu:bionic (Ubuntu 18.04) Dockerfile :
RUN git clone \
-c core.eol=lf \
-c core.autocrlf=false \
-c fsck.zeroPaddedFilemode=ignore \
-c fetch.fsck.zeroPaddedFilemode=ignore \
-c receive.fsck.zeroPaddedFilemode=ignore \
--depth=1 \
--branch master \
https://github.com/ohmyzsh/ohmyzsh.git \
/usr/share/oh-my-zsh \
# Adapt zshrc template
&& cd /usr/share/oh-my-zsh/ \
&& cp templates/zshrc.zsh-template zshrc \
&& sed -i 's/export ZSH=$HOME\/.oh-my-zsh/export ZSH=\/usr\/share\/oh-my-zsh/g' zshrc \
&& sed -i 's/# DISABLE_AUTO_UPDATE="true"/DISABLE_AUTO_UPDATE="true"/g' zshrc \
&& sed -i 's/source $ZSH\/oh-my-zsh.sh//g' zshrc \
&& sed -i 's/ZSH_THEME="robbyrussell"/ZSH_THEME="bira"/g' zshrc \
&& echo '\n \
\n \
ZSH_CACHE_DIR=$HOME/.cache/oh-my-zsh \n \
if [[ ! -d $ZSH_CACHE_DIR ]]; then \n \
mkdir -p $ZSH_CACHE_DIR \n \
fi \n \
\n \
source $ZSH/oh-my-zsh.sh \n \
' >> zshrc \
# Copy zshrc template to $HOME on user creation
&& ln /usr/share/oh-my-zsh/zshrc /etc/skel/.zshrc \
# Setting the default shell for new users has no effect since:
# 1. The default shell is specified when creating new users in entrypoint
# 2. The `ade enter` command will execute `bash` anyways
&& sed -i 's/DSHELL=\/bin\/bash/DSHELL=\/bin\/zsh/g' /etc/adduser.conf
There's also a simple way to do this as well:
Login as the root user and install zsh
sudo su
apt-get install zsh
Then login as another user of the system:
su username
export ZSH=/home/username/.oh-my-zsh
sh -c "$(curl -fsSL https://raw.github.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"
Follow same procedures for all users who want oh-my-zsh

%prep problems when building RPMs on CentOS 7

Following all the random guides on the net and even on here:
What is the minimum I have to do to create an RPM file?
Nothing seems to work with Centos 7 (surprise!)
It seems if you leave %prep in your spec file, rpmbuild will try its hardest to ./configure and make something. what I'm not sure.
here is a super basic .spec file I'm trying to make an rpm to just copy in a file.
$more newpackage.spec
Name: hello
Version: 1.2
Release: 1%{?dist}
Summary: Testing testing 1 2 3
License: Beer
URL: No
#so apparently now you have to have version numbers everywhere, even the tar files, uhg
Source0: hello-1.2.tar.gz
#and the breaking begins :-( why everything broke with you centos 7?
# BuildRoot: %{_tmppath}/%{name}-%{version}-root
# BuildRequires:
# Requires:
%description
nothing to see here folks
#well here is some of the confusion
#%prep
%setup -q
# ./configure missing? um yeahhhh
# %build
# %configure
# make %{?_smp_mflags}
%install
rm -rf %{buildroot}
mkdir -p %{buildroot}
%files
#/usr/bin/hello.sh
%{_bindir}/hello.sh
# %doc
# %changelog
in side the tar file is /usr/bin/hello.sh
which is shell script that just runs echo "hello world"
if i comment %prep rpmbuild complains about ./configure not being found.
rpmbuild -v -bb newpackage.spec
Looks like commenting out %build dosen't actully stop rpmbuild from trying to build the sources...
so if i DELETE out %build and %configure and that make line. things work

Resources