Which way is standard to generate IETF-syslog messages in the C language?
There is the header <syslog.h>. But it provide no options to use the STRUCTURED-DATA mechanism (rfc-5424).
Of course, messages could be constructed by hand directly to a socket. But it seems that such way is not standard.
Is there another standard way?
The standard way to do this is to have your application log messages using the normal openlog(), syslog() and closelog() routines from <syslog.h>.
That will send the messages to the syslogd running on the local machine. If the messages are then to be forwarded over the network using the syslog protocol, syslogd itself will take care of this. For example, this might be done using a target like #hostname in the syslogd.conf file.
In short, your application is expected to log messages to the syslogd, and syslogd decides where to send them (including over the network). This allows the local administrator maximum control.
Hmmm... that RFC is less than 2 years old. I don't think it is a big surprise to see that the ususal suspects haven't implemented it yet.
Related
I want to write a client and server in C preferably, simple C++ if necessary.
The server will run on some flavor of Linux, the client is for testing the server.
I want to ensure messages are received and error free; therefore I will use TCP.
I want them to communicate securely; thus I will use the latest version of TLS (v1.3).
I intend to use the GnuTLS library for reasons:
Actively updated by reputable open source project
License permits selling product
Given the above, if implemented and tested, I could claim that the client/server communication is secure, reliable (a.k.a. assured), and error-checked. Yes?
Am I missing something? Is anything patently false?
Edit: certificates... i think i'm missing something about certificates to protect against man in the middle attacks...
TLS is a complex topic. Depending on your specific code the TLS connection might succeed even if you fail to properly validate the certificate. Thus, just based on what you state so far in your question it cannot be assured that the data are transferred with proper end-to-end protection and that no man in the middle can manipulate the data.
I've got a general question about daemons in C, that I haven't seen an answer to by now.
Is there a way how one should implement the control of a daemon process, like a convention or standard?
--Rest is further explanation--
I have seen multiple documents teaching the basics how to create a daemon in C. Forking, closing file descriptors, changing root, etc... no problem. And they all stop, when the process enters a endless loop (when the daemon process is created - so to say). But this is only half the way when it comes to coding a daemon; you have to control it somehow. I can make it work different ways, but I have the feeling there is a lot more to it.
For this (checking if there is a process already running or for stopping a running daemon process, or ...) I have seen different approaches (UNIX sockets, file locks, pid-files, ...) with their pros and cons. But it seemed to me like opinions or personal flavors; "why don't you just...?" or "I've done it this way, it worked for me". And I am not sure if this is a sign of freedom or not.
I mean, if you take a look at sshd, httpd, syslogd, etc... they all can be controlled via init-scripts or the service command (start|stop|status). This looks like a standard. But is this just some loose convention a lot of people try to follow or is there some kind of "framework" in the deep sea of C functions? Do you have to make it work somehow - for example make your program respond to a "stop" argument and end the daemon process somehow? Or is there some kind of standard, convention, a UNIX-way, best practices... that one should follow to write "good, clean code" and that integrates well in most environments?
My main question comes down to: Is there a way it's meant to be done?
And if so, where could I find more information? I guess there is more to take care of, than just starting and stopping.
There is no standard, but there is a de facto standard, as you have already noticed.
I suggest you take one of those examples, such as Apache, and look into what apachectl does. You'll find it sends signals to the daemon, based on knowing the PID, which it reads from a file.
In the case of Apache, signals make sense, because you don't want some kind of HTTP request to be able to stop the server. In the case of a DBMS, you might want to respond to incoming commands to stop the server, provided you authenticate and authorize first.
You can use signals, or the daemon could create a unix socket (with appropriate permissions) and listen for data on in. It depends on how much control you need to implement over your program.
Remember that for low-traffic things, it can be convenient to use xinetd and let it fork and handle the connection, and just respond to the request.
This question might sound fool, because I know there are bunch of frameworks that does it for you. What I want is actually get in touch with low level C API deeply and able to write a program that sits on computer and intercepts packets between local machine and outer spaces. I tried to figure it out by looking at open source code (i.e. tcpdump) but it's quite difficult for me to find out which file actually performs network sniffing. Any suggestions would be appreciated !
You have to use raw socket. Here's an example.
At least for what concern Linux and Unix like operating systems. I don't know about Windows.
If you're using a UNIX based system[*] then the simplest mechanism is libpcap, which is part of the tcpdump project.
Your process will need root privileges to be able to access the network interface (as would also be the case with raw sockets).
Usually you'll end up having to decode ethernet frames, IP headers, etc yourself, although for most protocols this isn't that hard.
[*] It is actually available for Win32 as well, but I've not used it under Windows myself.
I want to implement a Unix daemon (let's call it myUnixd), and want the user to be able to interact with this daemon via the command line, for example:
myUnixd --help # will display help information
myUnixd --show # will show some data (the's deamon should be doing the work)
So my question is: How can I communicate with the daemon? I was thinking about Unix domain sockets. Can someone tell me the right way to do this?
Thanks.
Use Berkeley sockets. Specifically, you can create a "UNIX domain socket" (otherwise known as a "local domain socket," which will create what looks like a text file. Write to the text file to send text to the daemon, read from it to receive text from the daemon. You can implement this with a few function calls.
If you want something more advanced, you can also use DBus, which offers a more sophisticated interface, but which is more complicated to learn.
use tcp socket if you want to use telnet to communicate with your daemon.
One could also use Remote Procedure Call (RPC) for such client-server communication. There are different types of messages (protocols) that can be used together with it, one of them is JSON.
The JSON-RPC protocol is very well accepted for such tasks. You can find different tools and libraries to embed in your software. A quick search on google gives this C library. The advantage of such libraries is that from a JSON specification file, where you define all your remote function calls, it creates client and/or server stubs that you can just use in your code out of the box.
As a listener one can use sockets, as the other responses state, or just an embedded HTTP server like microhttpd (and libcurl for the client). There are plenty of examples out there to just reuse. HTTP allows you also to run your client behind a proxy.
The user, administrators and support staff need detailed runtime and monitoring information from a daemon developed in C.
In my case these information are e.g.
the current system health, like throughput (MB/s), already written data, ...
the current configuration
I would use JMX in the Java world and the procfs (or sysfs) interface for a kernel module. A log file doesn't seem to be the best way.
What is the best way for such a information interface for a C daemon?
I thought about opening a socket and implementing a bare-metal http or xmlrpc server, but that seems to be overkill. What are alternatives?
You can use a signal handler in your daemon that reacts to, say USR1, and dumps information to the screen/log/net. This way, you can just send the process a USR1 signal whenever you need the info.
You could listen on a UNIX-domain socket, and write regularly write the current status (say once a second) to anyone who connects to it. You don't need to implement a protocol like HTTP or XMLRPC - since the communication will be one-way just regularly write a single line of plain text containing the state.
If you are using a relational database anyway, create another table and fill it with the current status as frequent as necessary. If you don't have a relational database, write the status in a file, and implement some rotation scheme to avoid overwriting a file that somebody reads at that very moment.
Write to a file. Use a file locking protocol to force atomic reads and writes. Anything you agree on will work. There's probably a UUCP locking library floating around that you can use. In a previous life I found one for Linux. I've also implemented it from scratch. It's fairly trivial to do that too.
Check out the lockdev(3) library on Linux. It's for devices, but it may work for plain files too.
I like the socket idea best. There's no need to support HTTP or any RPC protocol. You can create a simple application specific protocol that returns requested information. If the server always returns the same info, then handling incoming requests is trivial, though the trivial approach may cause problems down the line if you ever want to expand on the possible queries. The main reason to use a pre-existing protocol is to leverage existing libraries and tools.
Speaking of leveraging, another option is to use SNMP and access the daemon as a managed component. If you need to query/manage the daemon remotely, this option has its advantages, but otherwise can turn out to be greater overkill than an HTTP server.