Systemd is well designed. It was conceived from the top, not just to fix bugs, but to be a correct implementation of the base system services. A systemd, may refer to all the packages, utilities and libraries around daemon. It was designed to overcome the shortcomings of init. It itself is a background process which is designed to start processes in parallel, thus reducing the boot time and computational overhead. It has a lot other features as compared to init while Sysvinit was never designed to cope with the dynamic/event-based architecture of the current Linux kernel. The only reason why we still use it today is the cost of a migration.
Systemd ships a growing number of useful, unified command-line interfaces for system settings and control (timedatectl, bootctl, hostnamectl, loginctl, machinectl, kernel-install, localectl). In Debian, they use the existing configuration files without breaking compatibility.
Systemd makes the boot process much simpler, entirely removing the need to specify dependencies in many cases thanks to D-Bus activation, socket activation, file/inotify activation and udev integration.
Systemd supports SELinux integration while SysV doesn't
Systemd can handle the boot process from head to toe, without needing to use any of the existing shell scripts. Systemd extends the logging features of the system in many ways with journald, and can remain integrated with the existing rsyslog daemon. Logs are in a structured format, attributed to filename, line of code, PID and service. They include the early boot (starting from initramfs). They can be quickly filtered and programmatically accessed through an efficient interface.
Systemd unit files, unlike SysV scripts, can usually be shipped by upstream, or at least shared with other distributions (already more than 1000 existing unit files in Fedora) without any changes, the Debian specifics being handled by systemd itself.
Systemd is incredibly fast (1 second to boot). It was not designed with speed in mind, but doing things correctly avoids all the delays currently incurred by the boot process.
The trition plan is easy, since existing init scripts are treated as first-class services: scripts can depend (using LSB headers) on units, units can depend on scripts. More than 99% of init scripts can be used without a modification.
It is not just init. It unifies, in fewer lines of code, everything that is related to starting services and managing session groups: user login, cron jobs, network services (inetd), virtual TTY management… Having a single system to handle all of that allows us to remove a lot of cruft, and to use less memory on the system.
When you have a process in progress which handle your prompt, there are some signals (orders) that we can send to theses process to indicate what we need:
Control+C sends SIGINT which will interrupt the application. Usually causing it to abort, but a process is able to intercept this signal and do whatever it likes: for instance, from your Bash prompt, try hitting Ctrl-C. In Bash, it just cancels whatever you've typed and gives you a blank prompt (as opposed to quitting Bash)
Control+Z sends SIGTSTP to a foreground application, effectively putting it in the background on suspended mode. This is very useful when you want the application to continue its process while you are doing another job in the current shell. When you finish the job, you can go back into the application by running fg (or %x where x is the job number as shown in jobs).
Sometimes sysadmins Linux need to save data safety and to this, it is recommended to compress the data. We have some methods or commands for compression on Linux. So frequently asked questions could be why should I use this command instead of another one example, why should I use tar instead of zip. To wer this, you should know the difference between the two.
tar is only an archiver whereas zip is an archiver and compressor. Tar uses gzip and bzip2 to achieve compression. With using tar command, we preserve metadata information of file and directories like seiuid, setgid and sticky bit information which are very important while zip doesn't preserve theses information. It is very important for criticals information. Other advantages of using tar is the fact that it assembles all the files into a single file to compress directly while zip compress file by file.
LVM is a logical volume manager. It requires to resize filesystem size. This size can be extended and reduced using lvextend and lvreduce commands respectively. You can think of LVM as dynamic partitions, meaning that you can create/resize/delete LVM partitions from the command line while your Linux system is running: no need to reboot the system to make the kernel aware of the newly-created or resized partitions. LVM also provides:
You can extend over more than one disk if you have more than one hard-disk. They are not limited by the size of one single disk, rather by the total aggregate size.
You can create a (read-only) snapshot of any LV (Logical Volume). You can revert the original LV to the snapshot at a later time, or delete the snapshot if you no longer need it. This is handy for server backups for instance (you cannot stop all your applications from writing, so you create a snapshot and backup the snapshot LV), but can also be used to provide a "safety net" before a critical system upgrade (clone the root partition, upgrade, revert if something went wrong).
you can also set up writeable snapshots too. It allows you to freeze an existing Logical Volume in time, at any moment, even while the system is running. You can continue to use the original volume normally, but the snapshot volume appears to be an image of the original, frozen in time at the moment you created it. You can use this to get a consistent filesystem image to back up, without shutting down the system. You can also use it to save the state of the system, so that you can later return to that state if you mess things up. You can even mount the snapshot volume and make changes to it, without affecting the original.
command > file.log 2>&1 : Redirect stderr to "where stdout is currently going". In this case, that is a file opened in append mode. In other words, the &1 reuses the file descriptor which stdout currently uses.
command 2>&1 | tee -a file.txt
nscd is a daemon that provides a cache for the most common name service requests. When resolving a user, group, host, service..., the process will first try to connect to the nscd socket (something like /var/run/nscd/socket).
If nscd has died, the connect will fail, and so nscd won't be used and that should not be a problem.
If it's in a hung state, then the connect may hang or succeed. If it succeeds the client will send its request (give IP address for www.google.com, passwd entries...). Now, you can configure nscd to disable caching for any type of database (for instance by having enable-cache hosts no in /etc/nscd.conf for the hosts database).
However, if nscd is in a hung state, it may not be able to even give that simple won't do wer, so that won't necessarily help. nscd is a caching daemon, it's meant to improve performance. Disabling it would potentially make those lookups slower. However, that's only true for some kind of databases. For instance, if user/service/group databases are only in small files (/etc/passwd, /etc/group, /etc/services), then using nscd for those will probably bring little benefit if any. nscd will be useful for the hosts database.
The Random Number Generator gathers environmental noise from device drivers and other sources into entropy pool. It also keeps an estimate of Number of bits of noise in entropy pool. It is from this entropy pool, random numbers are generated.
/dev/random will only return Random bytes from entropy pool. If entropy pool is empty, reads to /dev/random will be blocked until additional environmental noise is gathered. This is suited to high-quality randomnesses, such as one-time pad or key generation.
/dev/urandom will return as many random bytes as requested. But if the entropy pool is empty, it will generate data using SHA, MD5 or any other algorithm. It never blocks the operation. Due to this, the values are vulnerable to theoretical cryptographic attack, though no known methods exist.
For cryptographic purposes, you should really use /dev/random because of nature of data it returns. Possible waiting should be considered as an acceptable tradeoff for the sake of security, IMO. When you need random data fast, you should use /dev/urandom of course.
Both /dev/urandom and /dev/random are using the exact same CSPRNG (a cryptographically secure pseudorandom number generator). They only differ in very few ways that have nothing to do with “true” randomness and /dev/urandom is the preferred source of cryptographic randomness on UNIX-like systems.
For Linux sysadmins, it is frequent to access servers by ssh. But are we sure the communication established is really good secured?
There some additionals very simple steps that can be taken to initially harden the SSH service, such as:
In the work of sysadmin, we can sometimes want to check open ports on our remote server. But if we are on a machine where can not install nmap or we don't have the possibility to install a tool which can help us to check open ports, what could we do?
We can check it with bash using /dev/tcp or /dev/udp to open a TCP or UDP connection to the associated socket.
The command behavior is:
$ echo > /dev/tcp/$host/$port
we can associate a message to display if the port is opened
$ echo > /etc/tcp/126.96.36.199/53 && echo "OPEN PORT"
$ echo > /dev/tcp/188.8.131.52/80 && echo "GOOD" || echo "NOT OPEN"
-bash: connect: Connection timed out
-bash: /dev/tcp/184.108.40.206/80: Connection timed out