Andromeda Computer - Ilich Blanco
Ilich Blanco

Ilich Blanco

Entusiasta de la naturaleza y apasionado de la tecnología desde que puedo recordar, inversionista y fiel creyente de la tecnología blockchain y criptomonedas. Estoy seguro que los problemas de la sociedad y la humanidad en general no serán resueltos por economistas o sociólogos si no por la mente brillante de científicos.
Website URL: http://https://www.linkedin.com/in/ilichblanco Email: This email address is being protected from spambots. You need JavaScript enabled to view it.
Thursday, 14 November 2019 18:49

Learn to automate tasks in linux with cron jobs

Sometimes, you may have tasks that need to be performed on a regular basis or at certain predefined intervals. Such tasks include backing up databases, updating the system, performing periodic reboots and so on. Such tasks are referred to as cron jobs. Cron jobs are used for automation of tasks that come in handy and help in simplifying the execution of repetitive and sometimes mundane tasks. Cron is a daemon that allows you to schedule these jobs which are then carried out at specified intervals. In this tutorial, you will learn how to schedule jobs using cron jobs.

 

The Crontab file

A crontab file, also known as a cron table, is a simple text file that contains rules or commands that specify the time interval of execution of a task. There are two categories of crontab files:

1) System-wide crontab file

These are usually used by Linux services & critical applications requiring root privileges. The system crontab file is located at /etc/crontab and can only be accessed and edited by the root user. It’s usually used for the configuration of system-wide daemons. The crontab file looks as shown:

 cron1.png

 

The anatomy of a crontab file

Before we go further, it’s important that we first explore how a crontab file looks like. The basic syntax for a crontab file comprises 5 columns represented by asterisks followed by the command to be carried out.

* * * * * command

This format can also be represented as shown below:

m h d moy dow command

OR

m h d moy dow /path/to/script

Let’s expound on each entry

m: This represents minutes. It’s specified from 0 to 59

h: This denoted the hour specified from 0 to 23

d: This represents the day of the month. Specified between 1 to 31`

moy: This is the month of the year. It’s specified between 1 to 12

doy: This is the day of the week. It’s specified between 0 and 6 where 0 = Sunday

Command: This is the command to be executed e.g backup command, reboot, & copy

Managing cron jobs

Having looked at the architecture of a crontab file, let’s see how you can create, edit and delete cron jobs

Creating cron jobs

To create or edit a cron job as the root user, run the command

# crontab -e

To create a cron job or schedule a task as another user, use the syntax

# crontab -u username -e

For instance, to run a cron job as user Pradeep, issue the command:

# crontab -u Pradeep -e

If there is no preexisting crontab file, then you will get a blank text document. If a crontab file was existing, The -e option allows to edit the file,

Listing crontab files

To view the cron jobs that have been created, simply pass the -l option as shown

# crontab -l

Deleting a crontab file

To delete a cron file, simply run crontab -e and delete or the line of the cron job that you want and save the file.

To remove all cron jobs, run the command:

# crontab -r

That said, let’s have a look at different ways that you can schedule tasks

Crontab examples in Scheduling tasks. All cron jobs being with a shebang header as shown

#!/bin/bash

This indicates the shell you are using, which, for this case, is bash shell.

Next, specify the interval at which you want to schedule the tasks using the cron job entries we specified earlier on.

To reboot a system daily at 12:30 pm, use the syntax:

30 12 * * * /sbin/reboot

To schedule the reboot at 4:00 am use the syntax:

0 4 * * * /sbin/reboot

NOTE: The asterisk * is used to match all records

To run a script twice every day, for example, 4:00 am and 4:00 pm, use the syntax.

0 4,16 * * * /path/to/script

To schedule a cron job to run every Friday at 5:00 pm use the syntax:

0 17 * * Fri /path/to/script

OR

0 17 * * * 5 /path/to/script

If you wish to run your cron job every 30 minutes then use:

*/30 * * * * /path/to/script

To schedule cron to run after every 5 hours, run

* */5 * * * /path/to/script

To run a script on selected days, for example, Wednesday and Friday at 6.00 pm execute:

0 18 * * wed,fri /path/to/script

To schedule multiple tasks to use a single cron job, separate the tasks using a semicolon for example:

* * * * * /path/to/script1 ; /path/to/script2

Using special strings to save time on writing cron jobs Some of the cron jobs can easily be configured using special strings that correspond to certain time intervals. For example,

1) @hourly timestamp corresponds to 0 * * * *

It will execute a task in the first minute of every hour.

@hourly /path/to/script

2) @daily timestamp is equivalent to 0 0 * * *

It executes a task in the first minute of every day (midnight). It comes in handy when executing daily jobs.

@daily /path/to/script

3) @weekly timestamp is the equivalent to 0 0 1 * mon

It executes a cron job in the first minute of every week where a week whereby, a week starts on Monday.

@weekly /path/to/script

3) @monthly is similar to the entry 0 0 1 * *

It carries out a task in the first minute of the first day of the month.

@monthly /path/to/script

4) @yearly corresponds to 0 0 1 1 *

It executes a task in the first minute of every year and is useful in sending New year greetings ?

@monthly /path/to/script

Crontab Restrictions

As a Linux user, you can control who has the right to use the crontab command. This is possible using the /etc/cron.deny and /etc/cron.allow file. By default, only the /etc/cron.deny file exists and does not contain any entries. To restrict a user from using the crontab utility, simply add a user’s username to the file. When a user is added to this file, and the user tries to run the crontab command, he/she will encounter the error below.

 

 cron2.png

 

To allow the user to continue using the crontab utility, simply remove the username from the /etc/cron.deny file.

If /etc/cron.allow file is present, then only the users listed in the file can access and use the crontab utility.

If neither file exists, then only the root user will have privileges to use the crontab command.

Backing up crontab entries It’s always advised to backup your crontab entries. To do so, use the syntax

 

# crontab -l > /path/to/file.txt

 

For example,

 

# crontab -l > /home/james/backup.txt

 

Checking cron logs

 

Cron logs are stored in /var/log/cron file. To view the cron logs run the command:

 

# cat /var/log/cron

 

 cron3.png

 

To view live logs, use the tail command as shown:

# tail -f /var/log/cron


 cron4.png

 

Conclusion

In this guide, you learned how to create cron jobs to automate repetitive tasks, how to backup as well as how to view cron logs. We hope that this article provided useful insights with regard to cron jobs. Please don’t hesitate to share your feedback and comments.

 

BannerFinalGNULINUZROCKS

 

Monday, 11 November 2019 11:42

Lolis & Waifus EVERYWERE! #1

Hello to all the otakus who read me, it is an honor for me to present our collection number 1 of lolis and waifus in all its splendor. The platonic love of millions of otakus around the world will be in our new section Lolis & Waifus EVERYWERE! I hope you like it and enjoy it, let's just start!

 

 

 

 

 

 

 

terminalsudoancom.jpg

 

 

Think you know everything about sudo? Think again.

Everybody knows sudo, right? This tool is installed by default on most Linux systems and is available for most BSD and commercial Unix variants.

Still, after talking to hundreds of sudo users, the most common answer I received was that sudo is a tool to complicate life.

There is a root user and there is the su command, so why have yet another tool? For many, sudo was just a prefix for administrative commands.

Only a handful mentioned that when you have multiple administrators for the same system, you can use sudo logs to see who did what.

 

So, what is sudo? According to the sudo website:

"Sudo allows a system administrator to delegate authority by giving certain users the ability to run some commands as root or another user while providing an audit trail of the commands and their arguments."

By default, sudo comes with a simple configuration, a single rule allowing a user or a group of users to do practically anything (more on the configuration file later in this article):

%wheel ALL=(ALL) ALL

In this example, the parameters mean the following:

The first parameter defines the members of the group.

The second parameter defines the host(s) the group members can run commands on.

The third parameter defines the usernames under which the command can be executed.

The last parameter defines the applications that can be run.

So, in this example, the members of the wheel group can run all applications as all users on all hosts. Even this really permissive rule is useful because it results in logs of who did what on your machine.

 

Aliases

Of course, once it is not just you and your best friend administering a shared box, you will start to fine-tune permissions. You can replace the items in the above configuration with lists: a list of users, a list of commands, and so on. Most likely, you will copy and paste some of these lists around in your configuration.

This situation is where aliases can come handy. Maintaining the same list in multiple places is error-prone. You define an alias once and then you can use it many times. Therefore, when you lose trust in one of your administrators, you can remove them from the alias and you are done. With multiple lists instead of aliases, it is easy to forget to remove the user from one of the lists with elevated privileges.

 

Enable features for a certain group of users

The sudo command comes with a huge set of defaults. Still, there are situations when you want to override some of these. This is when you use the Defaults statement in the configuration. Usually, these defaults are enforced on every user, but you can narrow the setting down to a subset of users based on host, username, and so on. Here is an example that my generation of sysadmins loves to hear about: insults. These are just some funny messages for when someone mistypes a password:

[email protected]:~> sudo ls

 

[sudo] password for root:

 

Hold it up to the light --- not a brain in sight!

 

[sudo] password for root:

 

My pet ferret can type better than you!

 

[sudo] password for root:

 

sudo: 3 incorrect password attempts

 

[email protected]:~>

Because not everyone is a fan of sysadmin humor, these insults are disabled by default. The following example shows how to enable this setting only for your seasoned sysadmins, who are members of the wheel group:

Defaults !insults Defaults:%wheel insults

I do not have enough fingers to count how many people thanked me for bringing these messages back.

 

Digest verification

There are, of course, more serious features in sudo as well. One of them is digest verification. You can include the digest of applications in your configuration:

peter ALL = sha244:11925141bb22866afdf257ce7790bd6275feda80b3b241c108b79c88 /usr/bin/passwd

In this case, sudo checks and compares the digest of the application to the one stored in the configuration before running the application. If they do not match, sudo refuses to run the application. While it is difficult to maintain this information in your configuration—there are no automated tools for this purpose—these digests can provide you with an additional layer of protection.

 

Session recording

Session recording is also a lesser-known feature of sudo. After my demo, many people leave my talk with plans to implement it on their infrastructure. Why? Because with session recording, you see not just the command name, but also everything that happened in the terminal. You can see what your admins are doing even if they have shell access and logs only show that bash is started.

There is one limitation, currently. Records are stored locally, so with enough permissions, users can delete their traces. Stay tuned for upcoming features.

 

Plugins

Starting with version 1.8, sudo changed to a modular, plugin-based architecture. With most features implemented as plugins, you can easily replace or extend the functionality of sudo by writing your own. There are both open source and commercial plugins already available for sudo.

In my talk, I demonstrated the sudo_pair plugin, which is available on GitHub. This plugin is developed in Rust, meaning that it is not so easy to compile, and it is even more difficult to distribute the results. On the other hand, the plugin provides interesting functionality, requiring a second admin to approve (or deny) running commands through sudo. Not just that, but sessions can be followed on-screen and terminated if there is suspicious activity.

In a demo I did during a recent talk at the All Things Open conference, I had the infamous:

[email protected]:~> sudo rm -fr /

ommand displayed on the screen. Everybody was holding their breath to see whether my laptop got destroyed, but it survived.

 

Logs

As I already mentioned at the beginning, logging and alerting is an important part of sudo. If you do not check your sudo logs regularly, there is not much worth in using sudo. This tool alerts by email on events specified in the configuration and logs all events to syslog. Debug logs can be turned on and used to debug rules or report bugs.

Alerts Email alerts are kind of old-fashioned now, but if you use syslog-ng for collecting your log messages, your sudo log messages are automatically parsed. You can easily create custom alerts and send those to a wide variety of destinations, including Slack, Telegram, Splunk, or Elasticsearch. You can learn more about this feature from my blog on syslong-ng.com.

Configuration We talked a lot about sudo features and even saw a few lines of configuration. Now, let’s take a closer look at how sudo is configured. The configuration itself is available in /etc/sudoers, which is a simple text file. Still, it is not recommended to edit this file directly. Instead, use visudo, as this tool also does syntax checking. If you do not like vi, you can change which editor to use by pointing the EDITOR environment variable at your preferred option.

Before you start editing the sudo configuration, make sure that you know the root password. (Yes, even on Ubuntu, where root does not have a password by default.) While visudo checks the syntax, it is easy to create a syntactically correct configuration that locks you out of your system.

When you have a root password at hand in case of an emergency, you can start editing your configuration. When it comes to the sudoers file, there is one important thing to remember: This file is read from top to bottom, and the last setting wins. What this fact means for you is that you should start with generic settings and place exceptions at the end, otherwise exceptions are overridden by the generic settings.

 

 

You can find a simple sudoers file below, based on the one in CentOS, and add a few lines we discussed previously:

 

Defaults !visiblepw

Defaults always_set_home

Defaults match_group_by_gid

Defaults always_query_group_plugin

Defaults env_reset

Defaults env_keep = "COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS"

Defaults env_keep += "MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE"

Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin

root ALL=(ALL) ALL

%wheel ALL=(ALL) ALL

Defaults:%wheel insults

Defaults !insults

Defaults log_output

This file starts by changing a number of defaults. Then come the usual default rules: The root user and members of the wheel group have full permissions over the machine. Next, we enable insults for the wheel group, but disable them for everyone else. The last line enables session recording.

The above configuration is syntactically correct, but can you spot the logical error? Yes, there is one: Insults are disabled for everyone since the last, generic setting overrides the previous, more specific setting. Once you switch the two lines, the setup works as expected: Members of the wheel group receive funny messages, but the rest of the users do not receive them.

 

Configuration management

Once you have to maintain the sudoers file on multiple machines, you will most likely want to manage your configuration centrally. There are two major open source possibilities here. Both have their advantages and drawbacks.

You can use one of the configuration management applications that you also use to configure the rest of your infrastructure. Red Hat Ansible, Puppet, and Chef all have modules to configure sudo. The problem with this approach is that updating configurations is far from real-time. Also, users can still edit the sudoers file locally and change settings.

The sudo tool can also store its configuration in LDAP. In this case, configuration changes are real-time and users cannot mess with the sudoers file. On the other hand, this method also has limitations. For example, you cannot use aliases or use sudo when the LDAP server is unavailable.

 

New features

There is a new version of sudo right around the corner. Version 1.9 will include many interesting new features. Here are the most important planned features:

A recording service to collect session recordings centrally, which offers many advantages compared to local storage:

It is more convenient to search in one place.

Recordings are available even if the sender machine is down.

Recordings cannot be deleted by someone who wants to delete their tracks.

The audit plugin does not add new features to sudoers, but instead provides an API for plugins to easily access any kind of sudo logs. This plugin enables creating custom logs from sudo events using plugins.

The approval plugin enables session approvals without using third-party plugins.

And my personal favorite: Python support for plugins, which enables you to easily extend sudo using Python code instead of coding natively in C.

Conclusion I hope this article proved to you that sudo is a lot more than just a simple prefix. There are tons of possibilities to fine-tune permissions on your system. You cannot just fine-tune permissions, but also improve security by checking digests. Session recordings enable you to check what is happening on your systems. You can also extend the functionality of sudo using plugins, either using something already available or writing your own. Finally, given the list of upcoming features you can see that even if sudo is decades old, it is a living project that is constantly evolving.

If you want to learn more about sudo, here are a few resources:

BannerFinalGNULINUZROCKS

Sunday, 27 October 2019 14:16

The Man Who Gathers Memes #07

October is a strange month, but it is the best month of the year, better than December fucking. Yes I already said so what?

 

 

You can also visit previous posts with the best memes

portadamemesseptiembreingles.png

portadamarzo.png

memesaugoust.jpg

portadajunememes.jpg

 

portadamemesmay.jpg

 

Sunday, 27 October 2019 13:28

The Man Who Gathers Memes #06

Welcome to the September harvest, a month moved to the world of memes, of our universal culture that allows us to find situations, politics and life itself, an inalienable right we have.

You can also visit previous posts with the best memes

portadamemesmarzo.png

memesaugoust.jpg

portadajunememes.jpg

 

 

portadamemesmay.jpg

 

Sunday, 27 October 2019 11:35

The Man Who Gathers Memes #05

Welcome to the August harvest, that month was very fruitful, with very viral memes that play different topics. I hope you enjoy the post !!!!!

 

 

 

 

 

You can also visit previous posts with the best memes

memesaugoust.jpg

 

 portadajunememes.jpg

 

 

portadamemesmay.jpg 

Page 1 of 14
DMC Firewall is a Joomla Security extension!