有没有办法只允许指定的用户su（如使用visudo sudo）。 原因是我想为我的root帐户保留一个简单（弱）的密码，并且可以su / sudo的帐户只能使用pub / private密钥login到本机。 那么，所有其他账户将不能作为根或可以作为一个帐户。
我正在构build一个容器来调整负载平衡器的内核设置。 我更愿意使用单个特权容器将这些更改部署到映像中的主机上。 例如： docker run –rm –privileged ubuntu:latest sysctl -w net.core.somaxconn=65535 在testing中，更改只对那个容器起作用。 我的印象是，一个完全特权的容器改变/ proc实际上会改变底层操作系统。 $docker run –rm –privileged ubuntu:latest \ sysctl -w net.core.somaxconn=65535 net.core.somaxconn = 65535 $ docker run –rm –privileged ubuntu:latest \ /bin/bash -c "sysctl -a | grep somaxconn" net.core.somaxconn = 128 这是多么特权容器应该工作？ 我只是在做一些愚蠢的事情？ 什么是做出持久改变的最好方法？ 版本信息： Client version: 1.4.1 Client API version: 1.16 Go […]
哪种方法更好？ 对于桌面使用，似乎sudo更好，因为： 作为普通用户，我可以拥有更一致的历史 不需要记住两个密码，当我不经常执行pipe理工作时更是如此。 无需在安装时创build额外的root帐户。 但关于服务器pipe理？ 在服务器中，通常您已经创build了一个root帐户，并且您可能经常执行pipe理任务。 所以sudo的优势似乎已经不复存在了。 更重要的是，在大多数发行版中，在命令行上configurationsu很容易，只需将用户添加到轮组即可。 （在使用时你甚至可以传递-G wheel ）。因此，configurationsu可以很容易地自动化到shell脚本中。 但是对于sudo？ 您需要先添加用户，而不是交互式运行visudo 。 这是不好的，因为你不能将它自动化到shell脚本中。 （好吧，你可以。例如， echo '%wheel ALL=(ALL) ALL' >> /tmp/sudoers.tmp cp /etc/sudoers /etc/sudoers.old visudo -c -f /tmp/sudoers.tmp && mv /tmp/sudoers.tmp /etc/sudoers 但至less不是那么容易的。） 那么你有什么意见？ 对于你喜欢的服务器环境，sudo或su root？
当我做su -到根目录时，我的当前目录被设置为root的主目录。 有没有办法保持我当前的目录，很像sudo -s 。 或者是使用sudo的答案？
我正在自动化一个部署过程，我希望能够在我的机器上调用一个.sh文件，让它执行我的构build，并将.zip上传到服务器，然后在服务器上做一堆东西。 我需要做的事情之一就是要成为根。 所以，我想要做的是这样的： ssh [email protected] <<END_SCRIPT su – #password… somehow… #stop jboss service server_instance stop #a bunch of stuff here #all done! exit END_SCRIPT 这甚至有可能吗？
背景 我知道su – ， sudo su -和sudo <command>之间的区别： su – – 将用户切换到root用户，需要root密码 sudo su – – 将用户切换到root用户，只需要当前用户的密码 sudo <command> – 仅为特定命令授予root访问权限; 只需要当前用户的密码 我的问题是关于是否使用sudo su -在生产环境中是安全的做法。 一些想法： 似乎允许sudo su -通过访问根帐户根据个人用户密码构成安全风险。 当然，这可以通过执行严格的密码策略来缓解。 我不认为su -是更好的，因为它需要pipe理员共享实际的root密码。 允许用户完全切换到root帐户使得更难logging谁对系统进行了更改。 我在我的日常工作中看到过多个用户被授予sudo su – access的情况。 在开始工作之前，用户在login系统时首先执行sudo su – 。 那么，有一天有些事情会中断，而且在错误的目录中运行rm -rf *人是没有可追溯性的。 问题 鉴于上述担忧，允许用户使用sudo su -甚至是su -是否是一个好主意？ 是否有任何理由pipe理员将configuration用户帐户为sudo su -或su -而不是sudo <command> （除了懒惰）？ […]
可能重复： vim以root身份重新编辑 我可以发誓我看到这个问题。 但是在查看“vi”的每个search结果之后，我很难/懒惰。 我打开了一个文件，做了一个编辑，现在我意识到它是只读的，我已经打开它作为非root我。
注意：请在这篇文章的中间点附近阅读以“EDIT”开头的更新信息 – 这个问题的环境和背景已经改变 我已经在这里安装了一个bog标准的Debian 6.0，我决定把它放在Debian Testing软件库。 我通过replacesources.list中Squeeze回购的引用来实现这一点，以使用Testing回购。 安装软件包并重新启动后，尝试su时遇到以下错误 – 到另一个用户： root@skaia:~# su joebloggs – bash: cannot set terminal process group (-1): Inappropriate ioctl for device bash: no job control in this shell 如果我省略 – ，这不会发生。 请注意，用户可以成为正确的根，这似乎只发生在从根目录切换到其他人，并使用 – 获取该用户的环境。 谷歌在这里大多是无用的。 我能find的唯一的东西就是2011年对sux软件包的sux ，这些软件似乎在sux时间已经得到修复。 这看起来和嗅觉非常像一个升级错误，可以通过正确的方式调整正确的包装来解决。 我只是不知道从哪里开始 – 除此之外，我的系统完全正常，并按预期工作。 编辑 如上所述，这在Debian 稳定的机器上正在发生。 这次没有升级或什么东西，只是直接稳定。 是的，一年后。 仍然不知道问题是什么。 下面是它现在的样子（没有太大变化）： bash: cannot set […]
PostgreSQL用户默认在unix套接字上进行同等身份validation，其中unix用户必须与PostgreSQL用户相同。 所以人们经常用su或sudo来成为postgres超级用户。 我经常看到人们使用结构如： sudo su – postgres 而不是 sudo -u postgres -i 我想知道为什么。 同样，我已经看到： sudo su – postgres -c psql 代替 sudo -u postgres psql 如果没有sudo那么su版本就会变得有意义。 但是为什么在一个比prehisoric的UNIX或者Linux更less的情况下，你会使用sudo su ？
我在Ubuntu 11.04（ adduser –system ）中创build了一个用于运行某些cron作业的“系统”用户，但有时候我想通过手动运行命令来testing这些用户。 什么是最简单的方法来做到这一点？ su不起作用，因为用户拥有/bin/false作为shell（这对于cron来说很好）。 我已经手动将shell更改为/bin/bash来执行testing，然后再将其更改回来，但是我不知道是否有更简单的方法？