I have installed ApacheDS form this link
http://directory.apache.org/apacheds/download/download-linux-bin.html
It is installed in the opt folder.
How can I uninstall it?
Ok, so you must have root access then? The 32-bit .bin I've just downloaded attempted to install files to /opt/apacheds-[$VERNUM]/, /etc/init.d/, and /var/lib/apacheds-[$VERNUM]. Because all of those locations should be protected against user writes in all linux distributions by default that I'm aware of, I will assume you can escalate privileges as necessary to perform the following actions.
Another assumption I will go on is that you chose the default installation locations offered you when the .bin installer requested you provide configuration options for installation paths. When I ran it just now it asked me a question per path and I had only to press the "ENTER" key to continue using its defaults.
If you're uncertain about how to obtain root access try to prefix each command with sudo, and, failing that, try running the command su once alone before attempting to run any of the following.
### First verify install paths with root level find command
# find / -type d -name *apacheds* ; find /etc/init.d -name *apacheds*
### Review outputs of above commands and verify they match the following \
### globbing rm command before running it.
### CAUTION: If used incorrectly rm -rf could do some very annoying damage
# rm -rf /{opt,var/lib,etc/init.d}/apacheds*
Related
I'm behind a firewall and I have the fzf.tar.gz package which has the content of the git repo. How can I install fzf offline?
The install command ~/.fzf/install is reaching out to github.com. I'm on Redhat with no internet connection.
https://github.com/junegunn/fzf
This is just what I observed, I can't guarantee I didn't miss anything:
First, clone fzf to FZF_DIR on an online PC, then,
I'd suggest you to execute 'install' on an online PC to get necessary files
~/.fzf/bin/fzf this one is downloaded by install script
~/.fzf.bash this one is generated by install script
cp ~/.fzf/bin/fzf $FZF_DIR/bin
copy $FZF_DIR (with fzf binary in it) and .fzf.bash into your offline PC
ln -s $FZF_DIR ~/.fzf
source .fzf.bash in your .bashrc
Entire FZF_DIR is needed because it includes some other useful scripts sourced by .fzf.bash.
When sharing a git repo between wsl on windows10 and any linux, all files added/changed from wsl get the rw-rw-rw attributes, even if I explicitly do a chmod ug+x file.py before adding. If You do a ls -l in wsl all files are listed with rwxrwxrwx no matter what.
On linux I have to do a find . -name "*.py" -exec chmod ug+x {} \; on every pull/clone
What is the best way to fix this? Are there some settings in WSL? git hooks?
I assume your git repo is somewhere in the windows file system, i.e. in /mnt/c/path/to/git. In this case WSL sets all permissions in order
to best reflect the Windows permissions. (FAQ)
There is currently no way in the stable build to change this behavior. But with
the insider build 17063 the WSL team face this by implementing DrvFs support, which
allows setting the owner and mode of files using chmod/chown, and also
the creation of special files such as fifos, unix sockets and device
files. (Release Notes)
I had installed CLion(2016.2.3) IDE from CLion-2016.2.3.tar.gz file. I accidentally deleted the CLion-2016.2.3.tar.gz file and CLion-2016.2.3 folder(which I got after extracting CLion-2016.2.3.tar.gz). Now CLion isn't working. When I ran dpkg --list from terminal, CLion wasn't present in the output. I want to remove CLion completely(all its files, folders, dependencies, etc.(even the configuration files)). How do I remove it completely?
Run the following command in terminal to find all the directories and files containing clion in their name :-
$ sudo find . -iname "*clion*"
Then delete the directories and files you have found.
To delete directories/files, go to the location of that directory/file in terminal using cd and run the following command :-
$ sudo rm -rf DIRECTORY_NAME/FILE_NAME
Simple Steps are :
Delete the clion folder you have downloaded and extracted.
Remove cache in ~/. using the command : sudo rm -r ~/.Clion.
Also need remove settings: /home/user/.config/JetBrains
You need also to remove settings that are stored in ~/. directory. That's it for Unix/Linux.
All Clion's binaries are store inside the folder you deleted.
But Clion sets up preferences at first launch, and you may have a menu icon which is pointing nowhere.
I suggest you run something like find ~ -iname "*clion*" and investigate what is found. If you are using Gnome2 or MATE desktop you will certainly find .desktop files which are the icons you are looking for.
If you used snap to install you can uninstall using
sudo snap remove --purge clion
I have a problem whith my installation of docker. When I launch my docker-compose up I have this error :
front_1 | /var/lock/apache2 already exists but is not a directory owned by www-data.
front_1 | Please fix manually. Aborting.
I have this error because I add this line in my dockerfile conf :
RUN usermod -u 1000 www-data
But if I delete this line, my symfony project doesn't work with docker.
Do you have any ideas to solve my problem ?
Best regards
As I see it, you are trying to change UID of user www-data inside docker to have the same ID as host machine user UID (you), so you can open project files in your IDE.
This introduces file permissions problems on apache2 service, which can't read it's own files (config, pid,...), simply because it is not the same user anymore.
Quick 'dirty' solution is to change only owner of symfony project files to UID 1000, but keep group (GID) to the www-data. This applies only for dev machine. Else you don't needed it. Run command inside container.
chown -R 1000:www-data /home/project
You can create some bash alias inside docker to have it at hand.
Other option is to use ACL which will set existing files and folder with permissions, which will get inherited to newly created files under given folder. This could be put to bootstrap script inside container. But only for DEV mode. This way you won't need to run chown.
chown -R 1000:www-data /home/project #set for existing files
/usr/bin/setfacl -R -m u:www-data:rwx -m u:0:rwx -m u:1000:rwx /home/project
/usr/bin/setfacl -dR -m u:www-data:rwx -m u:0:rwx -m u:1000:rwx /home/project
Each -m is for a different user. First is www-data (apache2), second is 0 (root) and third is 1000 (you).
Remember UID can change anytime. So this could create security hole if mentioned users are not having proper UID.
I used second method only for folders, where PHP via apache2 sets permissions (uploaded files, cache,...), but host user needs to access these files.
I want to write a Dockerfile which exports a directory from a remote Subversion repository into the build context so I can work with these files in subsequent commands. The repository is secured with user/password authentication.
That Dockerfile could look like this:
# base image
FROM ubuntu
# install subversion client
RUN apt-get -y update && apt-get install -y subversion
# export my repository
RUN svn export --username=myUserName --password=myPassword http://subversion.myserver.com/path/to/directory
# further commands, e.g. on container start run a file just downloaded from the repository
CMD ["/bin/bash", "path/to/file.sh"]
However, this has the drawback of printing my username and password on the screen or any logfile where the stdout is directed, as in Step 2 : RUN svn export --username=myUserName --password=myPassword http://subversion.myserver.com/path/to/directory. In my case, this is a Jenkins build log which is also accessible by other people who are not supposed to see the credentials.
What would be the easiest way to hide the echo of username and password in the output?
Until now, I have not found any way how to execute RUN commands in a Dockerfile silently when building the image. Could the password maybe be imported from somewhere else and attached to the command beforehand so it does not have to be printed anymore? Or are there any methods for password-less authentication in Subversion that would work in the Dockerfile context (in terms of setting them up without interaction)?
The Subversion Server is running remotely in my company and not on my local machine or the Docker host. To my knowledge, I have no access to it except for accessing my repository via username/password authentication, so copying any key files as root to some server folders might be difficult.
The Dockerfile RUN command is always executed and cached when the docker image is build so the variables that svn needs to authenticate must be provided at build time. You can move the svn export call when the docker run is executed in order to avoid this kind of problems. In order to do that you can create a bash script and declare it as a docker entrypoint and pass environment variables for username and password. Example
# base image
FROM ubuntu
ENV REPOSITORY_URL http://subversion.myserver.com/path/to/directory
# install subversion client
RUN apt-get -y update && apt-get install -y subversion
# make it executable before you add it here otherwise docker will coplain
ADD docker-entrypoint.sh /enrypoint.sh
ENTRYPOINT /entrypoint.sh
docker-entrypoint.sh
#!/bin/bash
# maybe here some validation that variables $REPO_USER $REPO_PASSOWRD exists.
svn export --username="$REMOTE_USER" --password="$REMOTE_PASSWORD" "$REPOSITORY_URL"
# continue execution
path/to/file.sh
Run your image:
docker run -e REPO_USER=jane -e REPO_PASSWORD=secret your/image
Or you can put the variables in a file:
.svn-credentials
REPO_USER=jane
REPO_PASSWORD=secret
Then run:
docker run --env-file .svn-credentials your/image
Remove the .svn-credentials file when your done.
Maybe using SVN with SSH is a solution for you? You could generate a public/private key pair. The private key could be added to the image whereas the public key gets added to the server.
For more details you could have a look at this stackoverflow question.
One solution is to ADD the entire SVN directory you previously checked out on your builder file-system (or added as a svn:externals if your Dockerfile is itself in a SVN repository like this: svn propset svn:externals 'external_svn_directory http://subversion.myserver.com/path/to/directory' ., then do a svn up).
Then in your Dockerfile you can simply have this:
ADD external_svn_directory /tmp/external_svn_directory
RUN svn export /tmp/external_svn_directory /path/where/to/export/to
RUN rm -rf /tmp/external_svn_directory
Subversion stores authentication details (if it not disabled in configuration) at client side and use stored username|password on request for the subsequent operations on the same URL.
Thus - you have to run (successful) svn export in Dockerfile with username|password only once and allow SVN to use cached credentials (remove auth. options from command-line) later