Welcome to the new Linux Foundation Forum!

Best Of

Re: Container fails with no apparent reason

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.

Kind regards,

Pascal

pamvdam

Re: Container fails with no apparent reason

Stefan,

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.

Kind regards,

Pascal

pamvdam

Re: Container fails with no apparent reason

Hi Stefan,

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:

https://docs.docker.com/engine/reference/builder/#cmd

https://docs.docker.com/engine/reference/builder/#entrypoint

Regards,
-Chris

chrispokorni

Re: Knowledge check question editing /etc/passwd

Hi Andre,

I'm not pretty sure of that, but we are working on this. Look at what 'man usermod(8)' says:

[...]

-L, --lock
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.

Regards,
Luis.

luisviveropena

Re: Knowledge check question editing /etc/passwd

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 .

lee42x

Re: Knowledge check question editing /etc/passwd

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:

-l, --lock
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

Regards,
Luis.

luisviveropena

Re: Network policy not working using pods label selector

Hi Stefan,

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

https://kubernetes.io/docs/concepts/services-networking/network-policies/

Regards,
-Chris

chrispokorni

Re: Exercise 6.6 loadBalancer external IP in pending

Hi Stefan,

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:

https://kubernetes.io/docs/concepts/services-networking/service/#loadbalancer

Regards,
-Chris

chrispokorni