I have setup one nginx rule
location ~ /(sitemap.*) {
alias /var/www/html/sitemaps/$1;
}
This works good for cases that I want like example
My issue is that that in response headers content type is content-type: text/plain and not correct for xml file
Any way for nginx to automatically understand the content type and return proper header ?
I am facing an issue that everytime I hard restart my server (maybe went bananas due to out of memory, ddosed etc) supervisor fails to run. And the reason for that is identified and simply /var/run/supervisor directory is deleted.
I learned that /var/run folders are deleted on hard reboot (via ec2 panel for instance force stop then start), so my humble question is:
How can I execute this mkdir /var/run/supervisor after every hard reboot ?
Where is the perfect place to add such logic. I guess it is not /etc/profile for sure
(the rest works fine, supervisor is configured as service + uses unix sock at var/run/supervisor/supervisor.sock)
My ubuntu version:
lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.2 LTS
Release: 20.04
Codename: focal
lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.2 LTS
Release: 20.04
Codename: focal
and have installed certbot via apt-get
My issue is that it is the second time that certificates expire and the cron(also systemd service) installed by certbot is not working.
I see this file created:
/lib/systemd/system/certbot.timer
[Unit]
Description=Run certbot twice daily
[Timer]
OnCalendar=*-*-* 00,12:00:00
RandomizedDelaySec=43200
Persistent=true
[Install]
WantedBy=timers.target
/lib/systemd/system/certbot.service
[Unit]
Description=Certbot
Documentation=file:///usr/share/doc/python-certbot-doc/html/index.html
Documentation=https://letsencrypt.readthedocs.io/en/latest/
[Service]
Type=oneshot
ExecStart=/usr/bin/certbot -q renew
PrivateTmp=true
/etc/cron.d/certbot
# /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.
#
# Important Note! This cronjob will NOT be executed if you are
# running systemd as your init system. If you are running systemd,
# the cronjob.timer function takes precedence over this cronjob. For
# more details, see the systemd.timer manpage, or use systemctl show
# certbot.timer.
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(43200))' && certbot -q renew
My init system is systemctl:
[[ `systemctl` =~ -\.mount ]] && echo yes || echo no
yes
I see there timer registered:
systemctl list-timers | grep 'cert'
Fri 2022-03-25 17:36:31 UTC 6h left Fri 2022-03-25 02:41:57 UTC 8h ago certbot.timer certbot.service
I also tried to check timer calls to see if certbot timer was called at midnight one day before:
journalctl --since "2 days ago" -u motd-news.timer
-- Logs begin at Sun 2021-09-26 19:26:36 UTC, end at Fri 2022-03-25 11:37:03 UTC. --
Mar 25 09:54:16 ip-10-40-2-7 systemd[1]: motd-news.timer: Succeeded.
Mar 25 09:54:16 ip-10-40-2-7 systemd[1]: Stopped Message of the Day.
-- Reboot --
Mar 25 09:54:55 ip-10-40-2-7 systemd[1]: Started Message of the Day.
-- Reboot --
Mar 25 09:59:11 ip-10-40-2-7 systemd[1]: Started Message of the Day.
Mar 25 10:06:38 ip-10-40-2-7 systemd[1]: motd-news.timer: Succeeded.
Mar 25 10:06:38 ip-10-40-2-7 systemd[1]: Stopped Message of the Day.
-- Reboot --
Mar 25 10:08:45 ip-10-40-2-7 systemd[1]: Started Message of the Day.
I don't understand why certbot renew command this cron/timer is never called or is called and something fails (for this I need information where to check the logs).
I am learning about Kubernetes and wanted to provision one such cluster in AWS via the KOPS tool. Followed official tutorial then for short this one too https://medium.com/andcloudio/kubernetes-kops-cluster-on-aws-f55d197d8304
I also made sure to add the ssh key before trying to connect to the bastion host as explained here too https://kops.sigs.k8s.io/bastion/#using-the-bastion
All goes fine, nodes, workes, load balancers etc get created and bastion host too.
The only problem is that I cannot ssh into the bastion host with the key. I runed the ssh with -vvv to see verbose output and log is below. I don't understand what is the problem
ssh -A admin@${bastion_elb_url} -vvv
Warning: Permanently added 'bastion-single-k8s-local-noarfe-151938406.eu-central-1.elb.amazonaws.com,3.121.65.83' (ECDSA) to the list of known hosts.
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug2: key: /root/.ssh/id_rsa (0x55d6af4ea570), agent
debug2: key: /root/.ssh/id_dsa ((nil))
debug2: key: /root/.ssh/id_ecdsa ((nil))
debug2: key: /root/.ssh/id_ed25519 ((nil))
debug3: send packet: type 5
debug3: receive packet: type 7
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,[email protected],ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected]>
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /root/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey
debug1: Trying private key: /root/.ssh/id_dsa
debug3: no such identity: /root/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /root/.ssh/id_ecdsa
debug3: no such identity: /root/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /root/.ssh/id_ed25519
debug3: no such identity: /root/.ssh/id_ed25519: No such file or directory
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).
I am also posting key results to help troubleshooting:
root@vagrant:/srv# ssh-add -L
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCq9cN3EAEy0WiASY/IBkF9SPIpLv/bZt1tpLc95cb5fG++ac5VX36rA4XukJFtCAk6I4P82ysuqfZGUQNsB57yibz9rbKZ1bFfxRPyGZS22/1Omqb/8B2NlNpJx42sK4odyUj3G+KLCGCmID/AEDhbjeY7d99ZuE6g8aqrtSo0fwsmNHnpvDS8Dt0IjbLxg41Sms9tmYDLlc/tncAs9BmRvuhPbg+BDw+z7ecLneI7+TexDfhXbnZkYfjFLsfI8vWivOu8ptuGVvPkQz/MJo+MokZEzoGbVCAZP5mYSIz+LIFnnCoh5WOMsB3OZuwvelR5bBgWjQhvOaWOX8BuSU5v /root/.ssh/id_rsa
I am collecting the results of free -m command on an ubuntu server every 5 seconds, and preparing a time series graph based on the values of free and used columns.
free -m
total used free shared buff/cache available
Mem: 992 43 709 5 238 791
Swap: 979
Sometimes the server that I am monitoring has a pattern like below: graph
I do not understand how the free memory can go down and used memory stay constant. Can it be some swap happening or something else ?
