Can anyone help me translate the instructions for setting this up as a Linux Service (at http://books.sonatype.com/nexus-book/3.0/reference/install.html#service-linux) into English?
After following them as best I could, I get the following when starting the service:
su: user / does not exist
Here are the parts of the instructions which were unclear:
In the bin/nexus script remove the line below.
INSTALL4J_JAVA_PREFIX="su - $run_as_user -c"
The line in the file is actually
INSTALL4J_JAVA_PREFIX=""
but ok, I can remove that. However, the next instruction is:
Replace the entire link with this line:
exec su - $run_as_user "$prg_dir/$progname" $#
What is meant by "the entire link"? The thing I removed above? That was the first line in the file - therefore the three variables above have not yet been set.... and is probably the reason the script currently fails.
I'll get the book fixed, it shouldn't have this in it anymore.
Download the 3.0 release, this was just a bug in 3.0m7, and it has been fixed. You don't need to make these changes.
https://support.sonatype.com/hc/en-us/articles/217965118
The only things you need to do is edit $NEXUS_HOME/bin/nexus.rc, uncomment the run_as_user line, and set the value for it appropriately. Then just symlink $NEXUS_HOME/bin/nexus to /etc/init.d/nexus, and after that run chkconfig or update-rc.d depending on your Linux version.
Related
I'm running a udev rule on my 3D printing server to automatically create easily identifyable symlinks to some attached microcontroller boards, which worked perfectly fine on ubuntu 20.04.
The rule triggers on the usb vendor and product ids and runs a python script via the PROGRAM directive. The script connects to the Microcontroller boards and reads it's init sequence to get the board's 'name'. It then outputs a string like "aaaaaaa b cccccc" and only the first block (containing the name) is used in the udev rule.
However, it seems like the whole PROGRAM directive is not executed at all anymore, since I updated my system to ubuntu 22.04.1.
My udev rule currently looks like this (While debugging. Regularly it just contained lines 1 and 3. I added #2 for testing purposes because the hook in line 1 works and that script is executed):
KERNELS=="ttyUSB*", ENV{ID_VENDOR_ID}=="0403", ENV{ID_MODEL_ID}=="6001", ENV{ID_SERIAL_SHORT}!="AI046A0Q", ACTION=="add|remove", RUN="/bin/su me -c \"/opt/me/deviceReg.py -d %k -a %E{ACTION}\""
KERNELS=="ttyUSB*", ENV{ID_VENDOR_ID}=="0403", ENV{ID_MODEL_ID}=="6001", ENV{ID_SERIAL_SHORT}!="AI046A0Q", ACTION=="add|remove", PROGRAM="/opt/me/serialUdev.py -s %s{serial} /dev/%k", SYMLINK+="%c{1}", OWNER="me", GOTO="script_end"
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}!="AI046A0Q", PROGRAM="/opt/me/serialUdev.py -s %s{serial} /dev/%k", SYMLINK+="%c{1}", OWNER="me", GOTO="script_end"
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="A9QXPRV7", SYMLINK+="tty_MainSwitch", GROUP="dialout", OWNER="me", GOTO="script_end"
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="A9QOIMJ6", SYMLINK+="tty_Cooler", GROUP="dialout", OWNER="me", GOTO="script_end"
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="A9PTMHGV", SYMLINK+="tty_CurrentTransformer", GROUP="dialout", OWNER="me", GOTO="script_end"
The python scripts write to some logfiles which clearly indicate that only lines 1 and 4, 5 or 6 are executed.
Is there anything in line 3 that isn't supported anymore in the latest udev version? As I said, line 3 worked perfectly before I updated the system.
The last 3 lines are my current workaround. They work fine but that's not what I want to achive with this whole naming system at all.
The python script in lines 2 & 3 runs perfectly fine, either if called as standard user or as root. It would also deliver valid output if the '-s ' input data is not matching the uc board, is missing or is random garbage.
Does anyone have an idea why the script omits any line with a PROGRAM statement?
Ok, I was able to solve the issue.
I set udev's log level to debug too see what's actually happening when the device is handled. The script actually IS invoked but immediately failed during importing needed modules: The pyserial module could not be found.
The module is installed though, but obviously in a way it could not be imported.
However, I checked the python script again and changed the first line from #!/usr/bin/env python3 to #!/usr/bin/python3 and now it works again.
So my problem actually wasn't related to udev at all, it was just my python script.
I would like to use VS Code for python development. For this I need to install an extension, but searching for extensions results in an "ECONNREFUSED" error (407 when I'm using the Insiders build).
My settings.json file contains the following two lines:
"http.proxy": "http://username:password#proxyurl:port",
"http.proxyStrictSSL": false
The password does contain the # symbol, but that's escaped with %40.
I have already double-checked for any spelling mistakes, and I'm still getting the same error. I also tried leaving out either of the two lines or both, but to no avail.
Check the official documentation about proxy-server-support.
As it's written, VS Code has exactly the same proxy server support as Google Chromium, refer the chromium network-settings for more detais.
Assume the proxy uri is http://127.0.0.1:8118, use command like bellow:
code --proxy-server="http=127.0.0.1:8118;https=127.0.0.1:8118"
Or a simple trick with alias if you are in linux, put following line at the end of you ~/.bashrc or ~/.profile file.
alias code='code --proxy-server="http=127.0.0.1:8118;https=127.0.0.1:8118"'
I'm trying to add torrents to transmission from python. The code is shown below...
def download_movie(magnet_link):
os.system('transmission-gtk')
#webbrowser.open(magnet_link)
os.system('transmission-gtk ' + magnet_link)
As you can see I've tried 3 different options to add these torrents but none work.. I've also added XDG_RUNTIME_DIR="/run/user/1000" in the crontab file. The log in /var/mail is running the script but it shows: (transmission-gtk:14091): Gtk-WARNING **: cannot open display:. I've also run the command xhost + as said in http://www.thegeekstuff.com/2010/06/xhost-cannot-open-display/ but still the gtk-warning comes up. Anyone have any ideas? What I want eventually is that I run this script on a pi so if anyone has any alternatives, I'm all ears.. Thanks.
It's because you are trying to use GUI app where console one would be appropriate.
See man transmission-remote for details:
DESCRIPTION
transmission-remote is a remote control utility for transmission(1) and transmission-daemon(1).
I am attempting to get Phabricator running on Solaris over apache. The website is working, but all of the cli scripts are not. For example, phd.
The first problem, is that it is not passing arguments to the underling manage-daemons.php script that it invokes. Looking at the phd file, this does not surprise me:
$> cat phd
../scripts/daemon/manage_daemons.php
Now, given my default shell is bash, this isn't going to pass-through my arguments. To do this, I have modified the script:
#! /bin/bash
../scripts/daemon/manage_daemons.php $*
This will now pass-through the arguments, but it's now failing to find transative scripts it requires via relative path:
./phd start
Preparing to launch daemons.
NOTE: Logs will appear in '/var/tmp/phd/log/daemons.log'.
Launching daemon "PhabricatorRepositoryPullLocalDaemon".
[2014-05-09 19:29:59] EXCEPTION: (CommandException) Command failed with error #127!
COMMAND
exec ./phd-daemon 'PhabricatorRepositoryPullLocalDaemon' --daemonize --log='/var/tmp/phd/log/daemons.log' --phd='/var/tmp/phd/pid'
STDOUT
(empty)
STDERR
./phd-daemon: line 1: launch_daemon.php: not found
at [/XXX/XXX/libphutil/src/future/exec/ExecFuture.php:398]
#0 ExecFuture::resolvex() called at [/XXX/XXX/phabricator/src/applications/daemon/management/PhabricatorDaemonManagementWorkflow.php:167]
#1 PhabricatorDaemonManagementWorkflow::launchDaemon(PhabricatorRepositoryPullLocalDaemon, Array , false) called at [/XXX/XXX/phabricator/src/applications/daemon/management/PhabricatorDaemonManagementWorkflow.php:246]
#2 PhabricatorDaemonManagementWorkflow::executeStartCommand() called at [/XXX/XXX/phabricator/src/applications/daemon/management/PhabricatorDaemonManagementStartWorkflow.php:18]
#3 PhabricatorDaemonManagementStartWorkflow::execute(Object PhutilArgumentParser) called at [/XXX/XXX/libphutil/src/parser/argument/PhutilArgumentParser.php:396]
#4 PhutilArgumentParser::parseWorkflowsFull(Array of size 9 starting with: { 0 => Object PhabricatorDaemonManagementListWorkflow }) called at [/XXX/XXX/libphutil/src/parser/argument/PhutilArgumentParser.php:292]
#5 PhutilArgumentParser::parseWorkflows(Array of size 9 starting with: { 0 => Object PhabricatorDaemonManagementListWorkflow }) called at [/XXX/XXX/phabricator/scripts/daemon/manage_daemons.php:30]
Note I have obscured my paths with XXX as they give away sensitive information.
Now, obviously I shouldn't be modifying these scripts. This is an indication that some prerequisite is not set up properly.
It's clear to me that Phabricator is making some (bold) assumption about my setup. But I'm not quite sure what...?
These are supposed to be symlinks. For example, if you look at "phd" in the repository on GitHub, you can see that the file type is "symbolic link":
https://github.com/facebook/phabricator/blob/master/bin/phd
Something in your environment is incorrectly turning the symlinks into normal files. I'm not aware of any Git configuration which can cause this, although it's possible there is something. One situation where I've seen this happen is when a working copy was cloned, then copied using something like rsync without appropriate flags to preserve symlinks.
I was trying nagios.
following command works well when I execute from the console.
./check_http -I 10.0.0.76 -p 8080 --url="/MYServiceBus/" --post="<My Message xml>" --eregi=.Status_Code.0./Status_Code. -c 7 -w 5 -v
So I went ahead and added in nrpe.cfg
But then it started giving error in /var/log/messages
Unknown option specified in config file '/usr/local/nagios/etc/nrpe.cfg' - Line 246
Interesting part is that the actual command is at line 245.
And in fact there is another check_http commands in the same config file which are working fine.
Am I missing anything but obvious.
Thanks in advance.
regards,
Mohan
Looks like your NRPE is not reloading due to a syntax error in the configuration file.
You do not say whether you are running NRPE as a standalone daemon or via (x)inetd; also you have not shown the content of your file here, so it is hard to debug.
My guess would be that you have edited the nrpe.cfg file a Windows-like editor that has added a trailing ^M to line 246, which is causing the error. Or, there is an invalid character in the line which is causing the problem. If these are not the causes, you need to post the relevant block of lines for us to examine.
OK, got the issue. the request lenght was too much for the NRPE, reduced it and it worked after that.