IssueTracker

Thank you for opening this issue. It seems to me that a change (maybe an update) happened and you are no longer part of the “Google-sudoers” group, and as explained in this document about the guest environment [1]. As such, and in order to investigate this issue, please provide further information (output) about the OS distribution you are using and the guest environment [3][4]:

$uname -a

$systemctl list-unit-files \
| grep google | grep enabled

$yum list installed | grep google-compute

In case another community member is facing the same issue with a different distribution, please check these document links [3] [4] for alternatives to the last two commands.

Meanwhile, and as a workaround, you may try the following:

1.Use a different username:
- if in the browser click on the setting icon (top right), and click change Linux name in the drop down. [5]
- Using the SDK
$ gcloud compute ssh newusername@instance 

2. Enable OS Login on the instance (set "enable-oslogin=True" in metadata) and per this document [6]

I will be awaiting for your reply.

[1] https://github.com/GoogleCloudPlatform/compute-image-packages#accounts
[2] https://cloud.google.com/compute/docs/images#os-details
[3] https://cloud.google.com/compute/docs/instances/linux-guest-environment#wgei_services
[4] https://cloud.google.com/compute/docs/instances/linux-guest-environment#wgei_packages
[5] https://cloud.google.com/compute/docs/ssh-in-browser#login_username
[6] https://cloud.google.com/compute/docs/instances/managing-instance-access

fyi,

$ uname -a*Linux instance-1 3.10.0-862.9.1.el7.x86_64 #1 SMP Mon Jul
16 16:29:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux*


$ systemctl list-unit-files \
> | grep google | grep enabled*google-accounts-daemon.service                enabled
google-clock-skew-daemon.service              enabled
google-instance-setup.service                 enabled
google-network-daemon.service                 enabled *


$ yum list installed | grep
google-compute*google-compute-engine.noarch   2.8.6-1.el7
        @google-cloud-compute
google-compute-engine-oslogin.x86_64
python-google-compute-engine.noarch*


On Tue, Oct 16, 2018 at 6:21 AM <buganizer-system@google.com> wrote:

fyi,
$ uname -a
Linux instance-1 3.10.0-862.9.1.el7.x86_64 #1 SMP Mon Jul 16 16:29:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

$ systemctl list-unit-files \
> | grep google | grep enabled
google-accounts-daemon.service                enabled
google-clock-skew-daemon.service              enabled
google-instance-setup.service                 enabled
google-network-daemon.service                 enabled

$ yum list installed | grep google-compute
google-compute-engine.noarch   2.8.6-1.el7                      @google-cloud-compute
google-compute-engine-oslogin.x86_64
python-google-compute-engine.noarch

Hi,

 I have tried the work aground you have mentioned

1. (OS Login),it not working. I cannot find any of my files , no permission
to change folder also

Last login: Tue Oct 16 11:07:34 2018 from 74.125.41.167

/usr/bin/id: cannot find name for group ID 578680806
[platformcloudtest_gmail_com@instance-1 ~]$ ls
[platformcloudtest_gmail_com@instance-1 ~]$


2.I have Changed username also

I don't have permission to acesss other folders




On Tue, Oct 16, 2018 at 10:38 AM Aneesh MP <platformcloudtest@gmail.com>
wrote:

Same thing happened to my machines:
uname -a output: 3.10.0-862.11.6.el7.x86_64 #1 SMP Tue Aug 14 21:49:04 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

as a workaround I followed this document https://cloud.google.com/compute/docs/instances/managing-instance-access#enable_oslogin and enabled oslogin with metadata on VM. When I logged in next time it created new user account which is part of Google-sudoers. From this account sudo works fine.

Account that is no longer part of sudoers generates those logs:
Oct 12 00:40:38 m2-us-central1-c google-accounts: INFO Removing user arek.
Oct 12 00:40:38 m2-us-central1-c google_accounts_daemon: Removing user arek from group google-sudoers
Oct 12 00:40:38 m2-us-central1-c google_accounts_daemon: gpasswd: user 'arek' is not a member of 'google-sudoers'
Oct 12 00:40:38 m2-us-central1-c google-accounts: WARNING Could not update user arek. Command '['gpasswd', '-d', 'arek', 'google-sudoers']' returned non-zero exit status 3.

Hope that helps.

Arek

As you have mentioned ,the workaround worked for me also ,Also tried
without the OS login just added new user IAM & admin with Role Compute
Admin , Owner  Once logged in just changed the the username from
the Terminal Options->Change Linux Username and eneterd the command sudo -i
after this i could run sudo commands with no issues.

Regards


On Tue, Oct 16, 2018 at 6:27 PM <buganizer-system@google.com> wrote:

Thank you everyone.

Investigating the issue, it seems only instances created with images “centos-7-v20181009“ between October 9th and 11th are affected.  (equivalent releases for other distributions may also be affected). This was already mitigated with the new images from October 11th “centos-7-v20181011”.

Thus, in your case, it is recommended to recreate the instance with the new image for a permanent resolution unless if the workarounds above are sufficient for your use-cases.

As this issue has been already fixed (with new image releases), I am closing it now. Thank you again for reporting it.

Hi,
I don't think it's related to instances created with those images. My VMs were created Feb 18, 2017, 10:53:07 AM.
I lost sudo access on my VMs on October 11th right after this outage: https://status.cloud.google.com/incident/cloud-networking/18016
Same day before outage everything was OK.

Arek

Hello,

My case is similar to Arek . Creation time of Instance is Feb 9, 2018,
9:49:13 PM.I lost sudo access on my VMs on October 15th 2018 .  Everything
was ok before this.

Sanil


On Wed, Oct 17, 2018 at 5:35 PM <buganizer-system@google.com> wrote:

Thank you Arek and Sanil for the clarification.

Investigating further, and as for the network incident reported in comment#9, it is does not seem related. The incident was a connectivity issue and was resolved within the hour. I assume it is just a coincidence.

Explaining further about the google-sudoer issue, a minor release of the guest environment package was pushed (to the repository) on October 9th. Thus, new images included the update. But also and since the packages were updated in the repository, few instances that perform updates (e.g yum update) or automatic updates (e.g yum-cron) got affected.

On October 11th, the packages were fixed, and new images that include the packages fix (v20181011) were released, while the images from October 9th were deprecated.

However, the package fix did not resolve the issue with existing affected instances, but rather for new images, and those existing images that did not perform any update within the time frame. Thus, for all affected instances the workarounds above.

As such, and for a permanent resolution for affected instances, I forwarded this issue to the Compute Engine team who are already aware of the issue. They mentioned that they are working on a permanent fix for the next release. At the moment we cannot provide an ETA. But you can track this thread for any updates, or post additional comments.

I hope this clarifies the confusion, and thank you again for the clarification.

Thank you for your patience.

Our Compute Engine team has resolved the issue internally. Any effected users can fix the issue by updating to the latest version of the guest environment (running a standard update and upgrade).

sudo apt update
sudo apt upgrade google-compute-engine

Affected users can disable OS Login at any time. That said, we do consider OS Login the preferred way to manage access to instances since it provides manages access with IAM (during time of log in), allows for easy deprovisioning of users, and creates a consistent identity (same username, uid, etc) across your organization.

Can you give detailed steps to fix this ?

Because

delete

delete