Is safe to restart Dbus daemon after update on production system ?
Services and daemons use dynamically linked libraries and I use service Needrestart to determine which service should be restarted.
Updates in eg. libc6 causes restart for almost all daemons. I do not allow myself to restart Dbus (which provides communication interface across the system). Is there any potential risk to data loss, deadlock, ...?
My environment is based on Debian (Wheezy, Jessie) with services provides SMTP, HTTP, DNS, DHCP, SMB, FTP, etc... but no X applications.
Related
Use case is web service intended to run as an appliance on a headless Raspberry Pi. OS: Raspbian (Debian).
The web service is running under a non-root service account, using a custom-rolled Boost Beast-based web server (avoid!).
What I want to do: provide a button in the web interface, running in a remote user's browser that allows the system to be shut down or rebooted.
What I've tried so far ... (C/C++)
system("/usr/sbin/shutdown -P now"); // (or -r for reboot)
Fails with the messages:
... [3460]: Failed to set wall message, ignoring: Interactive authentication required.
... [3460]: Failed to power off system via logind: Interactive authentication required.
... [3460]: Failed to open initctl fifo: Permission denied
... [3460]: Failed to talk to init daemon.
I also tried creating a wrapper executable that has been SUID-ed to root, that in turn calls system("/usr/sbin/shutdown ...") with identical results. So even with root credentials, shutdown fails. (Also tried /sbin/reboot, which also fails).
The service in question is written in c++, and services a web socket. The web client app sends a web socket request to shut down the system; and the shutdown is performed in the C++ server code. Everything works fine when the server is started in an interactive session; but it does not work when running in a systemd service.
The web server itself is running as a systemd service using a system account (so no login credentials, and I really do not want login credentials for the service account).
I'm perfectly willing to reconfigure the system, or create a service specifically for this purpose if necessary, and to do what I can to address security issues. But I have no clue as to what the path forward is. The issue is particularly pressing because there's no shutdown button on an out-of-the-box Raspberry Pi (although I do plan to address that for my own Pi). The fact that one CAN install a shutdown button on a Raspberry Pi means there must be some what to do it.
Ideally, I'd like to leave the R-Pi in a state that's usable for other purposes. So a no-password boot into a shell isn't an attractive option. I don't think. And rsh-based solutions are unattractive because they would require the appliance to have a preinstalled login account, with pre-installed credentials (and we all know how THAT goes).
I solved the same issue by creating a C++ daemon, running as root, and listening ONLY on local host TCP port, in charge to shutdown the system when contacted by the web service.
Edit: Use https://man7.org/linux/man-pages/man2/reboot.2.html to shutdown the OS.
In order to set Network Interfaces on Ubuntu 16.04 LTS I've recently developed a C program which takes advantage of Netlink Sockets for interprocess communication between User-Space and Kernel-Space.
After having successfully changed the ip/gateway/netmask addresses (emulating some iproute2 functions), I need to permanently save these changes. Indeed, after reboot these changes are dropped.
I don't want to change the /etc/network/interfaces file nor use Network Manager, but programmatically communicate with the Linux Kernel.
There is any way of doing it?
Regards
When restarting the vmware-tools service on the Linux Guest is it necessary to also restart the vmware-tools service on the ESX? I ask because I have 2 other guests running on this ESX/blade.
I'm trying to resolve an obscure issue with SNMP traps not indicating guest health and have to schedule all work accordingly since I manage hundreds of Linux guests on ESX hosts.
no. and there is no vmware-tools service on the ESX. since you are talking about SNMP, the corresponding service should be hostd. unless your change does not solve the issue there is no need to restart hostd.
Restarting the Management agents on an ESXi or ESX host (1003490)
https://kb.vmware.com/kb/1003490
What is the difference between daemon and service ? (In windows or Linux).
A daemon is a background, non-interactive program. It is detached from the keyboard and display of any interactive user. The word daemon for denoting a background program is from the Unix culture; it is not universal.
A service is a program which responds to requests from other programs over some inter-process communication mechanism (usually over a network). A service is what a server provides. For example, the NFS port mapping service is provided as a separate portmap service, which is implemented as the portmapd daemon.
A service doesn't have to be a daemon, but usually is. A user application with a GUI could have a service built into it: for instance, a file-sharing application.
For more details: https://askubuntu.com/questions/192058/what-is-technical-difference-between-daemon-service-and-process
Daemons are processes running in the background and are not in your face.They do certain tasks at set times or responds to certain events.
In Windows, daemons are called services.
Daemon
From wikipedia:
A daemon is a computer program that runs as a background process,
rather than being under the direct control of an interactive user.
For example you want to ping google.com. That means something in your OS should know how to handle the Domain name resolution. That is a daemon.
More to read : Berkeley Internet Name Daemon (BIND)
Service
That name comes from Client Server Model. It means that an application runs as a service on a server, and a client version of the application is used to access the service. For example an Apache HTTP server application is a service on a server and a Chrome Browser is a client on a PC.
More to read: Client Server Model
A daemon is a computer program that runs as a background process, rather than being under the direct control of an interactive user.
A daemon is a subset of services that always run in memory waiting to service a request.
For example - crond , ftpd ,etc
Whereas, a Service is a server application or set of applications that runs in the background waiting to be used, or carrying out essential task. They are basically called in inter-process communication.
For example - httpd
Due to the peculiar nature of the application, I'm thinking of running servers such as Apache, Tomcat from within a chroot environment.
Using schroot and debootstrap, I'm able to create a clone of my 10.04 ubuntu(minimal ubuntu) inside chroot directory. I've install tomcat and apache inside chroot . But how do I access these two servers?
Can I access them like a normal apache/tomcat installed on parent server?
Can the parent OS access the apache/tomcat of chroot os?
First, which of these options is possible. Second, any caveats that I should handle with each of these options.
I want something like
Internet ---> [Main host Ubuntu 10.04 Apache ----> (chroot ubuntu Tomcat) ]
chrooting is one of the simplest forms of virtual machines. If your application is security-sensitive, you might consider running a more full-featured solution, such as OpenVZ, Xen, KVM, VirtualBox or commercial solutions, such as VMware and a few others.
That being said, you should really consider to view your chrooted OS as just another host in your network. When you'll be using just chroot, you can access it as localhost (127.0.0.1) with some port number you'll assign to it (chrooted system will effectively share port assignations with parent system), while using other virtualization solutions allows you to assign a normal separate IP to each virtual machine and run it much as you would run a separate physical box.
chrooting is fairly "weak" security solution, is parent and child share a lot of resources almost without limitations (i.e. memory, CPU, process pool, disc space, privileges, sockets, etc). They only limitation in fact is limited filesystem access (i.e. chrooted applications can access only a portion of whole file system), although it provides some degree of isolation.