ApacheDS startup, wrapper nod found - wrapper

I am hoping the group can help me. I have been using ApacheDS for development purposes for about 6 months and I am really happy with it. No problem running on Ubuntu linux on my laptop.
I recently started to create my production environment for the LDAP server. The production server is running in Atlantic.net Cloud environment on a dedicated server. I did the install of DS with no problems. But when I try to start DS I get the following error:
/opt/apacheds-2.0.0-M10/bin/apacheds: 1: eval: /opt/apacheds-2.0.0-M10/bin/wrapper: not found
the wrapper file is located where eval is looking, so I have no idea why "not found" is occurring.
If I call the wrapper directly, ./wrapper start default
I get:
-bash: ./wrapper: No such file or directory
Below is the bin directory
drwxr-xr-x 2 apacheds apacheds 4096 Feb 24 10:40 .
drwxr-xr-x 5 apacheds apacheds 4096 Feb 23 12:22 ..
-rwxr-xr-x 1 apacheds apacheds 15346 Feb 23 12:22 apacheds
-rwxr-xr-x 1 apacheds apacheds 99401 Feb 23 12:22 wrapper
Here is the entry for the passwd file
apacheds:x:1000:1000::/opt/apacheds-2.0.0-M10:/bin/sh
so I don't think it is a id issue.
I am running Ubuntu Linux 12.04 LTS (GNU/Linux 3.2.0-38-generic x86_64)
Has anyone ever seen anything like this? I have search google, but nothing has come up.

I am experiencing absolutely same behaviour. As of now I am using java (.tar not .deb or .bin) version without the wrapper. I can be started by bin/apacheds.sh script. It is not the best solution but it let me going.

You are probably trying to run a 64bit executable on a 32bit configuration...

Related

Why won't my systemd REDIS service start in RHEL 7.9?

So I'm not sure how to even figure out what's happening. Running redis-server version 6.2.5 on RHEL 7.9. I can start REDIS with the user I want to run it as from the command line. But when I try to start it as a systemd service with the REDIS.service file:
[Unit]
Description=REDIS Service
After=syslog.target network.target remote-fs.target nss-lookup.target
[Service]
Type=simple
User=myuser
Group=myuser
WorkingDirectory=/app/redis
ExecStart=/bin/redis-server /app/redis/primary.conf
Restart=on-failure
[Install]
WantedBy=multi-user.target
It fails. The journalctl entry shows:
Aug 27 08:57:18 computerName redis-server[119338]: 119338:C 27 Aug 2021
08:57:18.981 # Fatal error, can't open config file
'/app/redis/primary.conf': Permission denied
The redis directory and all of it's files are owned by the user I'm telling to run the service. I even went to the extent of putting 777 on the directory and files. Thanks for any help you can give me!
Eric
This server was a mess. There was previous install of redis on the server, the rpm database was corrupt, there were old services that weren't running but were still there. I had to do a lot of cleanup and perform a clean install and it started working.

Composer Akeneo installation Could not open input file composer.phar

I am trying to install a PIM named Akeneo. The system requirements are all checked:
https://docs.akeneo.com/2.3/install_pim/manual/system_requirements/system_requirements.html
I am on Apache2 / Ubuntu 16.04
My /var/www/ directory all belongs to www-data:www-data ( ran chown -R www-data:www-data to install )
Error message from server : “Could not open input file: composer.phar”
Googled about it , got many results, and looked on the forums on stakoverflow, found answers from 2010 to 2018. I think I have maybe found out that the problem could be linked with the file "composer.phar", the way symlinks work on apache2, and composer installed globally or "inside individual project(s)".
Following 2 tutorials, I had to install composer to continue the install for that PIM.
My server says:
Composer (version 1.10.10) successfully installed to:
/usr/local/bin/composer
If I navigate to cd ~ and run ls I see there is "composer.phar" and "composer-setup.php" here.
I am confused because the Akeno tutorial says:
After extracting the file, change into the Akeneo directory and run
the commands below:
cd /var/www/html/akeneo/pim-community-standard
sudo php -d memory_limit=3G ../composer.phar install --optimize-autoloader --prefer-dist
sudo php bin/console cache:clear --no-warmup --env=prod
...
I don't understand the composer.phar install part . There are no composer.phar file inside any directories : not in /var/www/html/akeneo/ and not in /var/www/html/akeneo/pim-community-standard
Was it supposed to generate a composer.phar file there ? Should it find composer.phar one level above ( ../composer.phar ) ? I doubled checked the Akeneo PIM files , and the original .rar archive has no composer.phar file. Or, is it something to do with a symlink that accesses the global "composer.phar" which was with the global install ? Regarding symlinks, there are some in the "vendor" fodler of the PIM, and runing ls -l -a gives :
lrwxrwxrwx 1 www-data www-data 28 Feb 5 2020 doctrine -> ../doctrine/orm/bin/doctrine
lrwxrwxrwx 1 www-data www-data 34 Feb 5 2020 doctrine-dbal -> ../doctrine/dbal/bin/doctrine-dbal
lrwxrwxrwx 1 www-data www-data 46 Feb 5 2020 doctrine-migrations -> ../doctrine/migrations/bin/doctrine-migrations
lrwxrwxrwx 1 www-data www-data 56 Feb 5 2020 requirements-checker -> ../symfony/requirements-checker/bin/requirements-checker
lrwxrwxrwx 1 www-data www-data 51 Feb 5 2020 var-dump-server -> ../symfony/var-dumper/Resources/bin/var-dump-server
There is a composer.json and composer.lock file inside /var/www/html/akeneo/pim-community-standard . So confused because the turorial says to be inside pim-community-standard directory and run this : php -d memory_limit=3G ../composer.phar install --optimize-autoloader --prefer-dist
I hope I can resume the install without breaking anything. Some posts give the solution of updating composer, or installing composer-phar, inside the project. I am honestly totally lost.
( I don't know if I should bring that up, but is docker needed (not talked about in tutorial - but I see a folder with "docker" in it and I know that composer and docker can work together sometimes )
I moved the composer.phar file into the app directory. Now the install advanced. It's not a technical issue a misconfiguration or anything like that.
It's a lack of information about Composer on the Akeneo site but it's probably assumed that users should have knowledge about Composer allready.
Solution for me : moving the "composer.phar" file (from 'home' for me ) to the /var/www/project/ (.. the correct level directory).
So for my case it was a global / local install issue , which is still unclear, and I will have to look deeper how to properly install composer. Not sure if my current setup will not cause any issue later since it's like I installed it globally at first then moved only one file.
Also, command "composer" is not returning anything. I do have the composer file in /usr/bin/ though. This is very strange.

Unable to mount files in Vagrant

Error description
I'm unable to mount files in Vagrant or Docker, so it seems like it's an issue caused by some kind of a permission error.
My OS is Ubuntu 18.04 LTS (Bionic Beaver), I'm not running any access control modules like SELinux as far as I'm aware.
The Docker-related discussion of the error is found in another question:
Unable to mount files in Docker
Troubleshooting Vagrant
As a result I'm unable to mount files into Vagrant boxes (even though I have vboxsf):
Vagrant was unable to mount VirtualBox shared folders. This is usually
because the filesystem "vboxsf" is not available. This filesystem is
made available via the VirtualBox Guest Additions and kernel module.
Please verify that these guest additions are properly installed in the
guest. This is not a bug in Vagrant and is usually caused by a faulty
Vagrant box. For context, the command attempted was:
mount -t vboxsf -o uid=1000,gid=1000 srv_salt /srv/salt
The error output from the command was:
/sbin/mount.vboxsf: mounting failed with the error: No such device
I have specified these statements in Vagrantfile and it works on my colleagues local builds, but in my build these files do not get mounted or copied into the boxes:
host.vm.synced_folder "salt/", "/srv/salt"
host.vm.synced_folder "pillar/", "/srv/pillar"
Conclusion
It seems something is very messed up on my local machine when it comes to copying over files, possibly has to do with how my user is configured and what access it has to mounting files into VMs and containers.
If anyone can shed some light on this I'd appreciate it.
Updates
1)
As user #BMitch suggested I went through my "Virtualbox Guest Additions" installation.
Whenever I do an update of my packages I log this into logfiles, found this from update-20180405_153850.txt, almost 2 months ago.
Preparing to unpack .../virtualbox-guest-additions-iso_5.1.34-0ubuntu1.16.04.2_all.deb ...
Unpacking virtualbox-guest-additions-iso (5.1.34-0ubuntu1.16.04.2) over (5.0.40-0ubuntu1.16.04.1) ...
But this doesn't make sense to me.. my bootstrapping script (vagrant up'ing the boxes) fails the first time I run it with this:
Vagrant was unable to mount VirtualBox shared folders. This is usually
because the filesystem "vboxsf" is not available. This filesystem is
made available via the VirtualBox Guest Additions and kernel module.
Please verify that these guest additions are properly installed in the
guest. This is not a bug in Vagrant and is usually caused by a faulty
Vagrant box. For context, the command attempted was:
mount -t vboxsf -o uid=1000,gid=1000 srv_salt /srv/salt
The error output from the command was:
/sbin/mount.vboxsf: mounting failed with the error: No such device
Traceback (most recent call last):
File "launch-vagrant.py", line 166, in <module>
main()
File "launch-vagrant.py", line 120, in main
vagrant()
File "launch-vagrant.py", line 95, in vagrant
main()
File "launch-vagrant.py", line 67, in main
start()
File "launch-vagrant.py", line 83, in start
_exec('vagrant', 'up')
File "launch-vagrant.py", line 129, in _exec
subprocess.check_call(list(args))
File "/usr/lib/python3.6/subprocess.py", line 291, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['vagrant', 'up']' returned non-zero exit status 1.
The second time I run it it succeeds but with the following warning message:
Copy iso file /usr/share/virtualbox/VBoxGuestAdditions.iso into the box /tmp/VBoxGuestAdditions.iso
Mounting Virtualbox Guest Additions ISO to: /mnt
mount: /dev/loop0 is write-protected, mounting read-only
Installing Virtualbox Guest Additions 5.2.11 - guest version is unknown
Verifying archive integrity... All good.
Uncompressing VirtualBox 5.2.11 Guest Additions for Linux........
VirtualBox Guest Additions installer
Removing installed version 5.2.11 of VirtualBox Guest Additions...
Copying additional installer modules ...
Installing additional modules ...
VirtualBox Guest Additions: Building the VirtualBox Guest Additions kernel modules.
This system is currently not set up to build kernel modules.
Please install the Linux kernel "header" files matching the current kernel
for adding new hardware support to the system.
The distribution packages containing the headers are probably:
kernel-devel kernel-devel-3.10.0-693.21.1.el7.x86_64
VirtualBox Guest Additions: Starting.
VirtualBox Guest Additions: Building the VirtualBox Guest Additions kernel modules.
This system is currently not set up to build kernel modules.
Please install the Linux kernel "header" files matching the current kernel
for adding new hardware support to the system.
The distribution packages containing the headers are probably:
kernel-devel kernel-devel-3.10.0-693.21.1.el7.x86_64
An error occurred during installation of VirtualBox Guest Additions 5.2.11. Some functionality may not work as intended.
In most cases it is OK that the "Window System drivers" installation failed.
Clearly, this is the VBox Guest Additions installed in the actual boxes and not on my local machine.
I did however change the file mode for /usr/share/virtualbox/VBoxGuestAdditions.iso so maybe that will fix the issue:
petrus#DD-XPS-15-9550:/usr/share/virtualbox$ ll
total 56656
drwxr-xr-x 3 root root 4096 maj 14 00:28 ./
drwxr-xr-x 384 root root 16384 maj 16 12:58 ../
drwxr-xr-x 2 root root 12288 maj 13 23:06 nls/
-rw-r--r-- 1 root root 57970688 apr 20 15:50 VBoxGuestAdditions.iso
-rwxr-xr-x 1 root root 2600 nov 29 2016 VBox.sh*
-rwxr-xr-x 1 root root 4163 apr 13 18:37 VBoxSysInfo.sh*
petrus#DD-XPS-15-9550:/usr/share/virtualbox$ sudo chmod ugo+w VBoxGuestAdditions.iso
[sudo] password for petrus:
petrus#DD-XPS-15-9550:/usr/share/virtualbox$ ll
total 56656
drwxr-xr-x 3 root root 4096 maj 14 00:28 ./
drwxr-xr-x 384 root root 16384 maj 16 12:58 ../
drwxr-xr-x 2 root root 12288 maj 13 23:06 nls/
-rw-rw-rw- 1 root root 57970688 apr 20 15:50 VBoxGuestAdditions.iso
-rwxr-xr-x 1 root root 2600 nov 29 2016 VBox.sh*
-rwxr-xr-x 1 root root 4163 apr 13 18:37 VBoxSysInfo.sh*
To the vagrant problem:
By default Vagrant mounted the folder of host Vagrant file to '/vagrant'. Test the output of 'ls -l /vagrant' if the basic file system mount works.
The 'ls' command should show your Vagrantfile as a minimum in '/vagrant'.
If the Vagrantfile is visible in the virtual machine basically the mount works with vagrant.
host.vm.synced_folder "salt/", "/srv/salt"
host.vm.synced_folder "pillar/", "/srv/pillar"
It seem you mount your additional folder relative to your Vagrantfile. In that case you can modify your VM internally to link them to the desired dest folder.
You can do that in the provision state of your VM for example.
# Vagrantfile snippet
config.vm.provision "shell", inline: <<-SHELL
ln -s /vagrant/salt /srv/salt
ln -s /vagrant/pillar /srv/pillar
SHELL
Maybe this file are not available at provision time then run them as one time task after your first login or put something similar to /etc/rc.local of your VM

How do I properly configure glassfish 4 to work with gurobi's shared library?

Error:
java.lang.UnsatisfiedLinkError: /opt/gurobi600/linux64/lib/libGurobiJni60.so: libgurobi60.so: cannot open shared object
It is getting the path correct when I add it via JVM settings, for some reason it doesn't find it if only relying on LD_LIBRARY_PATH environment variable though. Either way it has trouble with the libgurobi60.so. I tried adding all of this to glassfish_home/domains/domain1/lib/applibs and ext to no avail.
Here are the permissions for /opt/gurobi600/linux64/lib
-rw-r--r-- gurobi.jar
lrwxrwxrwx libgurobi60.so -> ./libgurobi.so.6.0.0
lrwxrwxrwx libgurobi_c++.a -> ./libgurobi_g++4.2.a
-rw-r--r-- libgurobi_g++4.1.a
-rw-r--r-- libgurobi_g++4.2.a
-rwxr-xr-x libGurobiJni60.so
-rwxrwxrwx libgurobi.so.6.0.0
I had this working on my previous server running ubuntu 12.04, this is now on 14.04. Previously copying the .so file to /usr/local/bin seemed to fix the issue, but this does not work on the new server.
Running the following two commands fixed it:
echo "/opt/gurobi600/linux64/lib" | sudo tee /etc/ld.so.conf.d/gurobi.conf
sudo ldconfig

"Symbolic link not allowed or link target not accessible" on fresh installed XAMPP for Linux

I did a fresh-install of XAMPP for Linux (version 1.7.4) on my Ubuntu 11.04 x64 laptop.
Then I made a link in my htdocs folder to my project folder:
$pwd
/opt/lampp/htdocs
$sudo ln -s /home/petra/projects/webapp webapp
$ls -al
drwxr-xr-x 4 nobody root 4096 2011-08-18 11:58 .
drwxr-xr-x 18 root root 4096 2011-01-25 15:33 ..
lrwxrwxrwx 1 root root 26 2011-08-18 11:42 webapp -> /home/petra/projects/webapp
When I opened the webapp in the browser using http://localhost/webapp, it only showed "403 Access Forbidden". The error log said:
$tail -f /opt/lampp/logs/error_log
[Thu Aug 18 11:43:15 2011] [error] [client 127.0.0.1] Symbolic link not allowed or link target not accessible: /opt/lampp/htdocs/webapp
Here is the httpd.conf. Strangely, the FollowSymLinks options are already defined (default).
There is a similar question on the XAMPP forum but I think nobody seems to pay attention to it anymore.
Does anyone have an idea how to fix this?
Try to run Apache using your user.
By default Apache runs as "www-data" so edit your apache2.conf, and search for "user" and set:
user=youruser
Restart Apache and voilà, it should work.
I found out that if I use link from directory outside /home/petra, the web-app is working normally. I guess it's because I use Encrypted Home Directory setting on my Ubuntu.
I just have to move the project directory outside my home directory to make it work.
I ran into this problem when I symlinked the document root to code sitting on my encrypted home directory. I also solved it by running apache as the user who owned the encrypted content.