История изменений
Исправление firkax, (текущая версия) :
Автор, тебе тут кучу всего написали, местами понятное, местами не очень, но подробностей того где ты не прав кажется так и не расписали.
---------------------------------------------------------------
Если ты пишешь что-то типа такого
ssh username@host command >> /some/file
1) команда для запуска - ssh
2) её аргументы - username@host и command (они передаются ssh-у и работает с ними исключительно он)
3) файл куда записать результат команды (то есть, внимание, результат работы ssh) - /some/file
При этом все эти действия (и запуск ssh и запись в файл) будут производиться от текущего пользователя (судя по символу $ который у тебя виден это не рут). То, что у тебя указано username@host - это, ещё раз, аргумент для ssh, который указывает куда подключаться. Но файл /some/file создаётся не ssh-ем и не на удалённом указанном хосте, а шеллом (bash?) в который ты ввёл эту команду. Весьма частая ошибка считать что «>> /some/file» отправится аргументом в команду (т.е. в данном случае в ssh). Если тебе действительно надо чтобы «>> /some/file» было частью команды, отправляемой в ssh, надо заключить в кавычки, вот так:
ssh root@xx.xx.xxx.xxx 'echo \'ETCD_ADVERTISE_CLIENT_URLS="http://xx.xx.xxx.xxx:2379, http://localhost:2379"\' >> /etc/default/etcd'
В таком виде команда будет рассматриваться так:
1) команда для запуска - ssh
2) её первый аргумент - root@xx.xx.xxx.xxx
3) её второй аргумент - echo 'ETCD_ADVERTISE_CLIENT_URLS="http://xx.xx.xxx.xxx:2379, http://localhost:2379"' >> /etc/default/etcd (благодаря кавычкам он передаётся как одно целое, и, обрати внимание, одинарные кавыки внутри самого аргумента надо было предварить обратными слэшами (\') чтобы показать что это не закрывающая кавычка второго аргумента ssh, а символ внутри него.
Таким образом, ssh запустится, подключится к руту на указанном хосте, и выполнит на нём команду echo с записью в файл. Сам ssh, как и раньше, будет запущен от не-рута, но действия, которые он отправляет на ту сторону, делаются уже рутом (включая запись файла на той стороне).
---------------------------------------------------------------
Вторая проблема. Ты считаешь, что с помощью chown root:root можно выдать кому-то какие-то права. Это не так. У рута и так есть права на всё, вне зависимости от того какой владелец и группа у файлов, а так же вне зависимости от того какой там chmod. То есть chown root:root может выполнить только одну функцию: удостовериться, что у не-рута прав тут не будет. У рута же они есть в любом случае.
Собственно, если руту пишет permission denied, то проблема точно не в правах на файлы. Скорее всего (как у тебя) ты просто перепутал рута с не-рутом. В других редких случаях это действительно может быть что-то с правами, но точно не с теми которые chown/chmod (ты скорее всего с этим не столкнёшься).
Исправление firkax, :
Автор, тебе тут кучу всего написали, местами понятное, местами не очень, но подробностей того где ты не прав кажется так и не расписали.
---------------------------------------------------------------
Если ты пишешь что-то типа такого
ssh username@host command >> /some/file
1) команда для запуска - ssh
2) её аргументы - username@host и command (они передаются ssh-у и работает с ними исключительно он)
3) файл куда записать результат команды (то есть, внимание, результат работы ssh) - /some/file
При этом все эти действия (и запуск ssh и запись в файл) будут производиться от текущего пользователя (судя по символу $ который у тебя виден это не рут). То, что у тебя указано username@host - это, ещё раз, аргумент для ssh, который указывает куда подключаться. Но файл /some/file создаётся не ssh-ем и не на удалённом указанном хосте, а шеллом (bash?) в который ты ввёл эту команду. Весьма частая ошибка считать что «>> /some/file» отправится аргументом в команду (т.е. в данном случае в ssh). Если тебе действительно надо чтобы «>> /some/file» было частью команды, отправляемой в ssh, надо заключить в кавычки, вот так:
ssh root@xx.xx.xxx.xxx 'echo \'ETCD_ADVERTISE_CLIENT_URLS="http://xx.xx.xxx.xxx:2379, http://localhost:2379"\' >> /etc/default/etcd'
В таком виде команда будет рассматриваться так:
1) команда для запуска - ssh
2) её первый аргумент - root@xx.xx.xxx.xxx
3) её второй аргумент - echo 'ETCD_ADVERTISE_CLIENT_URLS="http://xx.xx.xxx.xxx:2379, http://localhost:2379"' >> /etc/default/etcd (благодаря кавычкам он передаётся как одно целое, и, обрати внимание, одинарные кавыки внутри самого аргумента надо было предварить обратными слэшами (\') чтобы показать что это не закрывающая кавычка второго аргумента ssh, а символ внутри него.
Таким образом, ssh запустится, подключится к руту на указанном хосте, и выполнит на нём команду echo с записью в файл. Сам ssh, как и раньше, будет запущен от не-рута, но действия, которые он отправляет на ту сторону, делаются уже рутом (включая запись файла на той стороне).
---------------------------------------------------------------
Вторая проблема. Ты считаешь, что с помощью chown root:root можно выдать кому-то какие-то права. Это не так. У рута и так есть права на всё, вне зависимости от того какой владелец и группа у файлов, а так же вне зависимости от того какой там chmod. То есть chown root:root может выполнить только одну функцию: удостовериться, что у не-рута прав тут не будет. У рута же она есть в любом случае.
Собственно, если руту пишет permission denied, то проблема точно не в правах на файлы. Скорее всего (как у тебя) ты просто перепутал рута с не-рутом. В других редких случаях это действительно может быть что-то с правами, но точно не с теми которые chown/chmod (ты скорее всего с этим не столкнёшься).
Исправление firkax, :
Автор, тебе тут кучу всего написали, местами понятное, местами не очень, но подробностей того где ты не прав кажется так и не расписали.
---------------------------------------------------------------
Если ты пишешь что-то типа такого
ssh username@host command >> /some/file
1) команда для запуска - ssh
2) её аргументы - username@host и command (они передаются ssh-у и работает с ними исключительно он)
3) файл куда записать результат команды (то есть, внимание, результат работы ssh) - /some/file
При этом все эти действия (и запуск ssh и запись в файл) будут производиться от текущего пользователя (судя по символу $ который у тебя виден это не рут). То, что у тебя указано username@host - это, ещё раз, аргумент для ssh, который указывает куда подключаться. Но файл /some/file создаётся не ssh-ем и не на удалённом указанном хосте, а шеллом (bash?) в который ты ввёл эту команду. Весьма частая ошибка считать что «>> /some/file» отправится аргументом в команду (т.е. в данном случае в ssh). Если тебе действительно надо чтобы «>> /some/file» было частью команды, отправляемой в ssh, надо заключить в кавычки, вот так:
ssh root@xx.xx.xxx.xxx 'echo \'ETCD_ADVERTISE_CLIENT_URLS="http://xx.xx.xxx.xxx:2379, http://localhost:2379"\' >> /etc/default/etcd'
В таком виде команда будет рассматриваться так:
1) команда для запуска - ssh
2) её первый аргумент - root@xx.xx.xxx.xxx
3) её второй аргумент - echo 'ETCD_ADVERTISE_CLIENT_URLS="http://xx.xx.xxx.xxx:2379, http://localhost:2379"' >> /etc/default/etcd (благодаря кавычкам он передаётся как одно целом, и, обрати внимание, одинарные кавыки внутри самого аргумента надо было предварить обратными слэшами (\') чтобы показать что это не закрывающая кавычка второго аргумента ssh, а символ внутри него.
Таким образом, ssh запустится, подключится к руту на указанном хосте, и выполнит на нём команду echo с записью в файл. Сам ssh, как и раньше, будет запущен от не-рута, но действия, которые он отправляет на ту сторону, делаются уже рутом (включая запись файла на той стороне).
---------------------------------------------------------------
Вторая проблема. Ты считаешь, что с помощью chown root:root можно выдать кому-то какие-то права. Это не так. У рута и так есть права на всё, вне зависимости от того какой владелец и группа у файлов, а так же вне зависимости от того какой там chmod. То есть chown root:root может выполнить только одну функцию удостовериться, что у не-рута прав тут не будет. У рута же она есть в любом случае.
Собственно, если руту пишет permission denied, то проблема точно не в правах на файлы. Скорее всего (как у тебя) ты просто перепутал рута с не-рутом. В других редких случаях это действительно может быть что-то с правами, но точно не с теми которые chown/chmod (ты скорее всего с этим не столкнёшься).
Исходная версия firkax, :
Автор, тебе тут кучу всего написали, местами понятное, местами не очень, но подробностей того где ты не прав кажется так и не расписали.
---------------------------------------------------------------
Если ты пишешь что-то типа такого
ssh username@host command >> /some/file
1) команда для запуска - ssh
2) её аргументы - username@host и command (они передаются ssh-у и работает с ними исключительно он)
3) файл куда записать результат команды (то есть, внимание, результат работы ssh) - /some/file
При этом все эти действия (и запуск ssh и запись в файл) будут производиться от текущего пользователя (судя по символу $ который у тебя виден это не рут). То, что у тебя указано username@host - это, ещё раз, аргумент для ssh, который указывает куда подключаться. Но файл /some/file создаётся не ssh-ем и не на удалённом указанном хосте, а шеллом (bash?) в который ты ввёл эту команду. Весьма частая ошибка считать что «>> /some/file» отправится аргументом в команду (т.е. в данном случае в ssh). Если тебе действительно надо чтобы «>> /some/file» было частью команды, отправляемой в ssh, надо заключить в кавычки, вот так:
ssh root@xx.xx.xxx.xxx 'echo \'ETCD_ADVERTISE_CLIENT_URLS="http://xx.xx.xxx.xxx:2379, http://localhost:2379"\' >> /etc/default/etcd' В таком виде команда будет рассматриваться так: 1) команда для запуска -2) её первый аргумент -sshroot@xx.xx.xxx.xxx3) её второй аргумент -echo 'ETCD_ADVERTISE_CLIENT_URLS="http://xx.xx.xxx.xxx:2379, http://localhost:2379"' >> /etc/default/etcd(благодаря кавычкам он передаётся как одно целом, и, обрати внимание, одинарные кавыки внутри самого аргумента надо было предварить обратными слэшами (\') чтобы показать что это не закрывающая кавычка второго аргумента ssh, а символ внутри него. Таким образом, ssh запустится, подключится к руту на указанном хосте, и выполнит на нём команду echo с записью в файл. Сам ssh, как и раньше, будет запущен от не-рута, но действия, которые он отправляет на ту сторону, делаются уже рутом (включая запись файла на той стороне). --------------------------------------------------------------- Вторая проблема. Ты считаешь, что с помощью chown root:root можно выдать кому-то какие-то права. Это не так. У рута и так есть права на всё, вне зависимости от того какой владелец и группа у файлов, а так же вне зависимости от того какой там chmod. То есть chown root:root может выполнить только одну функцию удостовериться, что у не-рута прав тут не будет. У рута же она есть в любом случае. Собственно, если руту пишет permission denied, то проблема точно не в правах на файлы. Скорее всего (как у тебя) ты просто перепутал рута с не-рутом. В других редких случаях это действительно может быть что-то с правами, но точно не с теми которые chown/chmod (ты скорее всего с этим не столкнёшься).