Bug #940
Missing prelude-lml services on cross-compiled device
0%
Description
Hello,
currently I am trying to use prelude on 2 different systems. On device A runs libprelude, libpreludedb, mysql-server, prelude-manager, prelude-lml and prewikka. It is kind of a base station. This server runs as an Ubuntu 14.04 machine on Virtualbox.
On device B, I installed libprelude and prelude-lml. It is a switch with a custom Linux kernel, that's based on Debian. I had to cross-compile the libraries for system B by using buildroot.
I can establish a connection between the two nodes and register the lml-sensor on the manager. But the problem is that system B does not offer any services to start/stop/restart prelude-lml because the script is missing under /etc/init.d/
. How is this possible? I tried to add the script manually, but first it terminated unsuccessfully. It does, however, run just fine on device A. The script:
#!/bin/sh -e
### BEGIN INIT INFO
# Provides: prelude-lml
# Required-Start: $syslog $remote_fs
# Required-Stop: $syslog $remote_fs
# Should-Start: $local_fs
# Should-Stop: $local_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start prelude-lml sensor
### END INIT INFO
test $DEBIAN_SCRIPT_DEBUG && set -v -x
NAME=prelude-lml
PATH=/bin:/usr/bin:/sbin:/usr/sbin
DAEMON=/usr/bin/prelude-lml
PIDFILE=/var/run/$NAME.pid
DAEMONARGS="-d -q -P /var/run/$NAME.pid"
trap "" 1
export LANG=C
export PATH
test -f $DAEMON || exit 0
check_prelude_profile()
{
if [ ! -d "/etc/prelude/profile/$NAME" ]; then
echo "Prelude profile for $NAME was not found"
echo "You must create it with prelude-admin (see README.Debian)"
echo "NOT starting."
# do not return with an error, this would prevent package installation
exit 0
fi
}
case "$1" in
start)
echo -n "Starting Prelude LML: "
check_prelude_profile
start-stop-daemon --start --pidfile $PIDFILE --exec $DAEMON --oknodo \
--quiet -- $DAEMONARGS > /dev/null
echo "$NAME."
;;
stop)
echo -n "Stopping Prelude LML: "
start-stop-daemon --stop --pidfile $PIDFILE --exec $DAEMON --quiet \
--oknodo > /dev/null
echo "$NAME."
;;
restart|force-restart|reload|force-reload)
echo -n "Restarting Prelude LML: "
check_prelude_profile
start-stop-daemon --stop --pidfile $PIDFILE --exec $DAEMON --quiet \
--oknodo > /dev/null
start-stop-daemon --start --pidfile $PIDFILE --exec $DAEMON --oknodo \
--quiet -- $DAEMONARGS > /dev/null
echo "$NAME."
;;
*)
echo "Usage: $0 {start|stop|restart}"
exit 1
;;
esac
if [ $? -eq 0 ]; then
echo .
exit 0
else
echo failed
exit 1
fi
I tried to run the commands one by one afterwards. I realised that machine B also lacked a *.pid file as well as the whole ruleset folder under
/etc/prelude-lml/ruleset
. After copying this from machine A, the script terminates without an error, but it doesn't do anything.
I wanted to know if this is a known issue of a specific version or if buildroot is messing things up. Or am I doing something completely wrong? Any help is highly appreciated!
Best regards,
Sebastian
History
#1 Updated by Antoine LUONG about 6 years ago
- Status changed from New to Assigned
- Assignee set to Antoine LUONG
Hello,
It is normal that the init file is not present if you installed prelude-lml from the sources (we put it in the packaging, not the repository). The same goes with the rules, which have their own repository.
Can you try launching directly the "prelude-lml" command (without the service) and see if it works correctly?
Regards
#2 Updated by Sebastian K about 6 years ago
Hello,
thank you for the fast reply. I guess I installed it from sources with buildroot, as I specified the path to the github repository in my make-files. That's a relief as it has nothing to do with the buildroot make process.
Concerning the prelude-lml issue: after registering the sensor on Machine B (address 192.168.0.1) to my server machine A (address 192.168.0.10) via the command prelude-admin register "prelude-lml" "idmef:w" 192.168.0.10 --gid 0 --uid 0
and running the registration-server on A, I tried to run prelude-lml
on B. The output says
# prelude-lml
31 Dec 21:19:01 (process:710) INFO: PCRE plugin loaded 460 rules.
31 Dec 21:19:02 (process:710) INFO: Connecting to 192.168.0.10:4690 prelude Manager server.
31 Dec 21:19:02 (process:710) WARNING: prelude-client: error starting prelude-client: TLS server certificate not yet activated.
In order to register this sensor, please run:
prelude-admin register prelude-lml "idmef:w" 192.168.0.10 --uid 0 --gid 0
Profile 'prelude-lml' does not exist. In order to create it, please run:
prelude-admin register "prelude-lml" "idmef:w" <manager address> --uid 0 --gid 0.
I don't really know what to do with these messages. It says it can connect to the server but when I check for the prelude-lml process I can't find one. So I guess it has something to do with the warning?
Best regards
#3 Updated by Antoine LUONG about 6 years ago
It may be a misconfiguration issue when registering prelude-lml. Please post the output of the "prelude-admin list -l" command on both hosts.
Regards
#4 Updated by Sebastian K about 6 years ago
Here the output of machine A (server):
root@cba-VirtualBox:/home/cba# prelude-admin list -l
Profile UID GID AnalyzerID Permission Issuer AnalyzerID
----------------------------------------------------------------------------------
prelude-lml root root 3520212549068940 idmef:w admin:r 3947566089915782
prelude-manager prelude prelude 3947566089915782 n/a n/a
and of machine B (client):
# prelude-admin list -l
Profile UID GID AnalyzerID Permission Issuer AnalyzerID
----------------------------------------------------------------
prelude-lml root root 3155595597106119 idmef:w 3947566089915782
Regards,
#5 Updated by Antoine LUONG about 6 years ago
The configuration is OK, but it seems your machine B has an incorrect date defined:
31 Dec 21:19:01 (process:710) INFO: PCRE plugin loaded 460 rules.
#6 Updated by Sebastian K about 6 years ago
Hello,
setting the date via date -s
on the client resolved the issue. That's the last thing I would have suspected, but it makes sense somehow.
Thanks for the great support!
Regards,
#7 Updated by Antoine LUONG about 6 years ago
- Status changed from Assigned to Resolved