![]() NOTE: Using this approach, after running your command, probably your access to the shell will be gone. Then, you can overwrite your sudoers file: pkttyagent -p $(echo $$) | pkexec cp ~/sudoers /etc/sudoers If you want to recover the default /etc/sudoers, you can use this gist to copy the default configurations, putting it in a non-root accessed place (e.g. If you want to remove a corrupted file in sudoers.d directory, use this: pkttyagent -p $(echo $$) | pkexec rm /etc/sudoers.d/FILENAME In this situation, using pkttyagent can be helpful. When this happens to a non-GUI system (your production server, maybe) the pkexec fails with this error message: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error.Failed: No session for cookieĮrror executing command as another user: Not authorized (which will prevent you from saving a sudoers file with incorrect syntax). Or, even better, you can edit it with sudo visudo -f /mnt/etc/sudoers Then you can edit the installed system's sudoers file with sudo nano -w /mnt/etc/sudoers. Then you could mount it with sudo mount /dev/sda1 /mnt. Suppose the installed Ubuntu system's root filesystem is on /dev/sda1. You can do this by running sudo parted -l to view your partitions-there is probably just one ext4 partition, and that's the root filesystem. ![]() If that doesn't work-for example, if there are no users authorized to run programs as root via PolicyKit-then boot from an Ubuntu live CD (like the CD you probably used to install Ubuntu) and mount the filesystem for the installed system. (If there is more than one user account on the system authorized to run programs as root with PolicyKit, then for any of those actions, you'll be asked to select which one you want to use, before being asked for your password.) Generally speaking, any non-graphical command you'd run with sudo can be run with pkexec instead. If you have a related situation where you have to perform additional system administration commands as root to fix the problem (also uncommon in this circumstance, but common in others), you can start an interactive root shell with pkexec bash. ![]() If you need to edit one of the configuration files in /etc/sudoers.d (which is uncommon in this situation, but possible), use pkexec visudo -f /etc/sudoers.d/ filename. If you have physical access to the machine, SSH is unnecessary just open a Terminal window and run that pkexec command.Īssuming you (or some other user) are authorized to run programs as root with PolicyKit, you can enter your password, and then it will run visudo as root, and you can fix your /etc/sudoers. To do this via SSH, log in to the machine and run the command pkexec visudo. These images weren't malicious or annoying as much as they were alerting visitors to current promotions and specials in an unobtrusive way.On a modern Ubuntu system (and many other GNU/Linux distributions), fixing a corrupted sudoers file is actually quite easy, and doesn't require rebooting, using a live CD, or physical access to the machine. I guess the lesson is: Be careful what you name your images. While I was able to fix the layout issues with CSS before finding Kabir's solution, the CSS was somewhat unnecessary and affected the flexibility of the slider to handle images of multiple sizes. Turn it off and/or rename your image files.Īlso, because of the inline CSS created by AdBlock, the layout of my promotions slider was being thrown off. If any of these things is happening to you, it probably has something to do with AdBlock. ![]() Later I noticed that these inline styles were added to all the image elements: display: none !important įinally, I did not receive any "failed to load resource" messages in the console, but rather this: Port error: Could not establish connection. The redirect request headers were all for this identical short line of base64-encoded data, and each returned no response, although the status was "Successful": GET data:image/png base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAACklEQVR4nGMAAQAABQABDQottAAAAABJRU5ErkJggg= HTTP/1.1 Later down the line, there was a second request that listed the original URL and then "Redirect" as the Initiator. The first request would return no response (Status "(pending)"). I was using Chrome's network tab to debug and finding very confusing results for these specific images that failed to load. This wasn't a cross-domain issue for me, and it failed on both localhost and on the web. My image URL was /images/ads/homepage/small-banners01.png,Īnd this was tripping up AdBlock. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |