I'd like to know the meaning of the alert message that occurs in the Linux time zone.
timedatectl
Warning: Ignoring the TZ variable. Reading the system's time zone setting only.
Local time: Mon 2019-11-18 12:12:50 JST
Universal time: Mon 2019-11-18 03:12:50 UTC
RTC time: Mon 2019-11-18 03:12:50
Time zone: Asia/Tokyo (JST, +0900)
Tell me the cause of the warning message and how to resolve it.
This command, hwclock --localtime, returns UTC time listed by timedatectl, instead to local.
First run
sudo timedatectl
if it showed the right timezone then skip ahead to ls -al /etc/localtime, otherwise correct it using
sudo timedatectl set-timezone <your region>/<your location>
as an example if you lived in Sweden you would run:
sudo timedatectl set-timezone Europe/Stockholm
then after running this check the output of
ls -al /etc/localtime
if this points to the wrong timezone then run
sudo rm /etc/localtime
followed by
sudo ln -sf /usr/share/zoneinfo/<your region>/<your location> /etc/localtime
substituting your region and your location with the same ones used in the last command.
That should fix it, though you might need to reboot for the changes to take affect.
Related
I ran into the following line while setting up the server in ubuntu. When logging in or accessing as root, the following message is displayed as a warning. Do you know how to get rid of this phenomenon?
root#ubuntu:~# sudo -i
Unknown operation st.
root#ubuntu:~#
or
ssh connection
Last login: Thu Jan 13 12:16:33 2022 from
Unknown operation st.
root#ubuntu:~#
Maybe it's an issue occurs while your shell sourcing.
Try checking your ~/.bashrc file or any other shell config files(/etc/profile, ~/bash_profile, ~/.profile etc)
I'm trying to code a bash script that set Time and Date manually, this work but after reboot my system (Ubuntu 18.04) time and date resets to automatic mode. How I can write a bash for set time/date that not change after reboot?
My try as a beginner ended to this Bash script:
#!/bin/bash
# A simple bash script to set system date & time
timedatectl set-ntp 0
date +%Y%m%d -s $1
date +%T -s $2":00"
timedatectl set-ntp 0 && timedatectl set-time 'HH:MM:SS' will turn off web clock sync and let you update it manually.
I done it by using Hard Ware Clock.
Task: Run chromium on startup on openSUSE
So far:
First I don't know what path to take, it's possible with Cron or from rc.local. I don't know which opinion is the best
Cron:
Figured out that it's not a very good idea
rc.local
So I have this script:
Fri Aug 11; 06:10:38; marton;/etc/init.d ; $ cat /etc/init.d/chrom_start.sh
#!/bin/bash
/usr/lib64/chromium/chromium
exit 0
I have permissions for the file:
Fri Aug 11; 06:11:09; marton;/etc/init.d ; $ ls -l /etc/init.d/chrom_start.sh
-rwxrwxr-x 1 root root 48 Aug 11 06:10 /etc/init.d/chrom_start.sh
openSUSE doesn't have update-rc.d
Fri Aug 11; 06:12:48; marton;/etc/init.d ; $ update-rc.d
If 'update-rc.d' is not a typo you can use command-not-found to lookup the package that contains it, like this:
cnf update-rc.d
I can't seem to find the example:
Fri Aug 11; 06:13:18; marton;/etc/init.d ; $ cat /etc/init.d/skeleton
cat: /etc/init.d/skeleton: No such file or directory
Somewhere I found that I have to use install job but it does not exist
Fri Aug 11; 06:20:35; marton;/etc/init.d ; $ %install
bash: fg: %install: no such job
So, if everything is alright, I just have to find a way to set the daemon to run on startup, what do I do next, considering that I don't have this skeleton file and these install job does not exist?
I don't know if it'll be of help on OpenSUSE, but here is a thread about "how to autostart Chromium" :
https://raspberrypi.stackexchange.com/questions/38515/auto-start-chromium-on-raspbian-jessie-11-2015
This may help too.
If you are using bash (it is the most probable scenario) you could edit your .bash_profile file, or .bash_login (both should be in your user's home directory).
You need to add at the end your chromium's path like:
/usr/bin/chromium&
the final & is to make it run as a background process. If you want to apply this change for every user you can edit your .bash_login file on /etc/skel
Hope it helps,
ps. here is an url that may help a bit.
http://tldp.org/LDP/Bash-Beginners-Guide/html/sect_03_01.html
I've seen conflicting recommendations. From the eff.org docs:
if you're setting up a cron or systemd job, we recommend running it twice per day... Please select a random minute within the hour for your renewal tasks.
I've also seen recommendations for weekly jobs.
I'm not a cron expert, so I'd prefer an answer with detailed steps for setting up the cron job.
I recently (April 2018) installed and ran certbot (version 0.22.2) on an Ubuntu 16.04 server, and a renewal cron job was created automatically in /etc/cron.d/certbot.
Here's the cron job that was created:
# /etc/cron.d/certbot: crontab entries for the certbot package
#
# Upstream recommends attempting renewal twice a day
#
# Eventually, this will be an opportunity to validate certificates
# haven't been revoked, etc. Renewal will only occur if expiration
# is within 30 days.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(3600))' && certbot -q renew
Please check this before putting a new Cron job.
Update (From #Hamish Downer's comment):
It's worth being aware that the above cron job won't run certbot renew if /run/systemd/system is present - this is because instead a systemd timer is running certbot - read more about certbot and systemd timers here.
So I settled on scheduling it to run once a day. First I tested auto-renew as the docs recommend:
sudo letsencrypt renew --dry-run --agree-tos
Then I updated the crontab:
sudo crontab -e
This is the line I added:
12 3 * * * letsencrypt renew >> /var/log/letsencrypt/renew.log
This runs the renew everday at 3:12 am. I presume the docs recommend "a random minute within the hour" to distribute the load on the renew servers. So I suppose anything other than 0, 15, 30, or 45 is preferred.
I looked into randomizing the minute in the cron setting, like Jenkins allows you to do.
On original EEF page is this Example:
0 0,12 * * * python -c 'import random; import time; time.sleep(random.random() * 3600)' && /usr/local/bin/certbot-auto renew
Finally, I tested the cron command using sudo bash:
sudo bash -c "letsencrypt renew >> /var/log/letsencrypt/renew.log"
In Debian Jessie and up (incl. Ubuntu) cron is not executed for Certbot renewal.
Instead the systemd timer is used. See timer: /lib/systemd/system/certbot.timer
This timer runs the following service: /lib/systemd/system/certbot.service
Which contains:
[Service]
Type=oneshot
ExecStart=/usr/bin/certbot -q renew
PrivateTmp=true
In order to list all the timers, execute the following command in the terminal:
systemctl list-timers
Hopefully Certbot is part of this:
Mon 2019-02-04 08:38:45 CET 9h left Sun 2019-02-03 15:25:41 CET
8h ago certbot.timer certbot.service
UPDATE:
Due to the down votes. I'll add how to install Certbot on a Debian based distro (it may vary depending on your Linux distribution).
But within Debian Stretch for example you can install the back-port package of certbot via:
sudo apt-get install certbot -t stretch-backports
This will install the files I showed above for you automatically! And thus automatically schedule a certbot timer for you, which runs the service, which runs again the renew.
Manually running a renew is always possible via:
sudo /usr/bin/certbot renew
Can be forced via --force-renewal flag. For more info see the help text of renew:
/usr/bin/certbot --help renew
Files part of the certbot package (incl. but not limited by):
dpkg-query -L certbot
...
/lib/systemd/system/certbot.service
/lib/systemd/system/certbot.timer
...
Ok. So being on Debian (or Ubuntu) with systemd I had probably the same problem like others - cron job not firing. I needed to make some extra steps and observations not mentioned elsewhere, so making separate answer for it.
In my case the /etc/systemd/system/ directory exists, so the job in /etc/cron.d/certbot stops at the initial test.
BUT the /etc/systemd/system/certbot.timer was a pointer to /dev/null. That means it is a masked timer. When I did systemd unmask certbot.timer the link was removed, but I had nothing to replace it with (tried locate certbot.timer but none was installed on my system). I could also still see the timer in systemd list-timers --all, but it was an emtpy file so removed that too using systemd disable certbot.timer. The service in /etc/systemd/system/certbot.service was completely absent.
So after actually cleaning all the certbot-related stuff from /etc/systemd/system/ I created the necessary files manually.
# /etc/systemd/system/certbot-renewal.service
[Unit]
Description=Certbot Renewal
[Service]
ExecStart=/usr/local/bin/certbot -q renew --post-hook "systemctl reload nginx"
# /etc/systemd/system/certbot-renewal.timer
[Unit]
Description=Run certbot twice daily
[Timer]
OnCalendar=*-*-* 00,12:00:00
RandomizedDelaySec=43200
Persistent=true
[Install]
WantedBy=timers.target
The timer file content comes from this answer.
I started and checked the whole thing by running:
sudo systemctl start certbot-renewal.timer
sudo systemctl enable certbot-renewal.timer
sudo systemctl list-timers --all
sudo journalctl -u certbot-renewal.service
Few more notes:
I have certbot in /usr/local/bin/certbot instead of /usr/bin/certbot (figured using which certbot), don't know why.
I'm using nginx, so need to reload it in the post-hook to take the renewed certs into account.
Normally while you run a certbot for any webserver in an Ubuntu 16.04 server it automatically creates a cron
#cat /etc/cron.d/certbot
0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(3600))' && certbot -q renew
Adding the following line to /etc/crontab runs renewal attempt daily on a random minute between 00:00 and approximately 16:40:
1 1 * * * root sleep ${RANDOM:0:3}m && /home/admin/certbot-auto renew --quiet --no-self-upgrade --authenticator webroot --installer apache -w /var/www/mywebroot
Works great for more than a year now.
The renew command itself may vary for you - I used webroot as it seemed most robust at that time.
for renew every 2 month:
#nano /etc/cron.d/certbot
30 03 01 */2 * echo "2" | certbot --nginx -v -d yourdomain.com
To keep simple set a timer to validate automatically:
systemctl status certbot.timer
I am having problems getting the 'at' command to run a script file:
This one works fine:
[myid#els-e37620 init.d]$ at now + 2 min
at> echo "this is my test" | write myid >/dev/null 2>&1
at> <EOT>
job 20 at Thu Jan 30 17:26:00 2014
But nothing happens when I try to run my script with 'at':
[myid#els-e37620 init.d]$ at now + 2 min
at> ./users/myid/bashtest.sh
at> <EOT>
job 21 at Thu Jan 30 17:31:00 2014
As far as I have seen the job is added to the 'at' queue and removed after the designated time but nothing happens! Is it executed somewhere else?
Thanks very much
The at command is usually disabled due to possible security issues. In the old days, it was possible to set an at job, then go into the queue and change the script including the environment before the job started.
One of the things you need to look at are the at.allow and at.deny files. These are sometimes kept under the /etc directory, sometimes under /var and sometimes under /usr/lib/cron. You'll need to look in your at manpage to find the actual location. If there's an empty at.allow file, then you cannot run any at jobs.
Another thing you should look at the manpage of your atrun command. The atrun command is what executes the at jobs. On some systems, the atrun command must be setup in the root's crontab file. On Macs, it's run by the launchd daemon, and you must run the launchctl command to start the atrun process.