In your post of 16 April, after 600s your command will 'fall through'. The sleep will be a completed command after 10min and it exits with a exit code (probably 0). But that's not what the POD is expecting. So it restarts. So either it gets killed by the probe and restarted or eventually it gets restarted just because your command has finished.
If you have more questions, just let me know.
Like above, the issue is dat your POD has one single container with the NGINX image, but you are starting the command:
"/bin/sh -c env"
Ergo; this wil print the env vars and then exit. It is a POD with a finite workload. The process exists after having done it's job. As it's the main proces in the container, the container will also exit. It's a finite proces. As the restart policy is Always; the container will get restarted with the same result -> it exits. You can play with this by for example substituing your command content with "sleep 3600". This will let the container live for 1h and then exit and the circus will start all over.
This is normal 'designed' behaviour. This kind of workload (which is finite) is best suited using a job/cronjob. Workload that is infinite (actually never ends like a webapp always listening for connection on a socket) is best suited with a ReplicaSet or Deployment.
In your prior post, your liveness container behaves according to its PodSpec: it performs a task, and then it completes. Depending on the restart policy, a continuous loop will have your container restarted.
From the most recent output, it seems that the test-container running the nginx image behaves as expected, based on your PodSpec. If you need help understanding container behavior, I recommend reading up on key instructions used when building container images. The following instructions should clarify the difference between a container running with its default configuration and an executable container:
I'm not pretty sure of that, but we are working on this. Look at what 'man usermod(8)' says:
Lock a user's password. This puts a '!' in front of the encrypted password, effectively disabling the password. You can't use this option with -p or -U.
Note: if you wish to lock the account (not only access with a password), you should also set the EXPIRE_DATE to 1.
And for locking the account we use the 'chage' command.
Look what the question in KC 30.1 says: "For a system capable of password aging on a per user basis, which of the following are valid ways of locking a user account? Select all answers that apply".
So, I think we should include or select the 'chage' tool. I'm still unsure about usermod and passwd, as these tools can lock the password but not the account (and those are slightly different things).
So, we are still looking at this.
Hello andre.kit , Luis
I did some checking as well, the /etc/passwd file entry #2 (password) needs to be an "x" to function, any other or additional characters are passed along to "crypt(3)" and will cause a failure in authentication. This is the same for the /etc/shadow file, any changes to the password entry will cause a failure.
Now the kicker, changing the /etc/passwd, 2nd entry to "xx" will inhibit normal login (including ssh) however, I can still
launch a process as the user and run programs. Consider:
$ sudo su - student ## does not check the password for student because su was launched as root and now other programs can be run student as long as additional authentication is not required.
As for the question, yes, it need to be updated.
To "lock" an account I would use "sudo usermod -e 1 -L .
Hi @andre.kit ,
You are right! I just did a small test case, and editing /etc/passwd (second field) with '!!' locks the account. I was researching if there is any difference between 'locking' and 'disabling', and I didn't find anything at the first search. But 'man passws(1)' shows the following:
Lock the password of the named account. This option disables a password by changing it to a value which matches no possible encrypted value (it adds a ´!´ at the beginning of the password).
Note that this does not disable the account. The user may still be able to login using another authentication token (e.g. an SSH key). To disable the account, administrators should use usermod --expiredate 1 (this set the account's expire date to Jan 2, 1970).
Users with a locked password are not allowed to change their password.
So, as far as I understand at the moment, there is a small difference between locking and disabling. I'm gonna double check it and I'll update this thread later, but it seems you are right
I would recommend reading up on the network policy documentation. In the introductory sections, you will find explained how the policy behaves once you introduce selectors. It may be the opposite of what you would expect
Unless your Kubernetes release is configured to talk to the underlying infrastructure, such as a manager Kubernetes service, you may not have an external service listening for API requests for an external Load Balancer.
You can read more about it here:
Typically they are called primary containers. There are such references in the documentation also. Here is an example where you find the term:
You can try looking directly in the .../s_05/ directory to find the required files. EXAMPLES is just a typo, introduced here in error.
The credentials to retrieve the newer resources version are the same, you can find them in the course material, just as before.