Home / user-109394

Grodriguez's questions

Martin Hope
Grodriguez
Asked: 2017-02-02 00:56:38 +0800 CST
  • 1

I have installed letsencrypt on Ubuntu 14.03 following this guide:

https://www.digitalocean.com/community/tutorials/how-to-secure-apache-with-let-s-encrypt-on-ubuntu-14-04

I also created a cron job for certificate renewal as described in the guide, but then found the following problem:

  • certbot-auto renew (as a non-root user) and sudo certbot-auto renew both work when tested from the command line (certbot reports that the certificates are not due for renewal yet, as expected)
  • However, when the same command is run by cron (as root), certbot tries to upgrade itself.

Any idea why I am getting this different behaviour? What is the difference between running the command manually on a shell console and having it run by cron?

Update: I added --no-self-upgrade but it didn't make any difference. On further investigation I noticed the following:

  • sudo certbot-auto renew --dry-run works fine
  • sudo su; certbot-auto renew --dry-run tries to upgrade certbot first

For some reason, certbot seems to think it is not properly installed when running in the second form.

cron lets-encrypt ubuntu-14.04
Martin Hope
Grodriguez
Asked: 2015-01-17 09:26:33 +0800 CST
  • 0

Normally sysv init scripts are run at boot time (from /etc/init.d/rcS) with the 'start' argument. However they can also be invoked with the 'start' after boot, for exmaple when a service is stopped and then manually restarted.

Is there a "standard", generic way for an init script to differentiate between the first run (at boot) and subsequent runs? (other than manual solutions such as creating a file on the first run and checking for it on subsequent runs)

init.d
Martin Hope
Grodriguez
Asked: 2012-02-04 03:50:19 +0800 CST
  • 21

I have a system running linux that must run unattended for long periods of time. The system uses industrial CF card for storage. Most of the time there are no writes to flash, although every now and then some configuration data/settings can be modified. The system must be resistant to power failures.

I would like to use ext4 for this. What is the best way to configure ext4 for this kind of setup? Bearing in mind that:

  • Performance is not a problem at all (especially write performance)
  • Upon power loss, the system should always boot in a clean state, even if that means that data written in the last few seconds is lost
  • If it is possible to avoid fsck, then all the better.

(I am aware of this related question: Prevent data corruption on ext4/Linux drive on power loss)

ext4