Feature requests and questions #153

Closed
opened 2021-11-20 15:20:20 +00:00 by ungleich-gitea · 14 comments

Created by: iredmail

  • doc: How about encourage user to install cdist with easy_install, pip from pypi? git version may be not so stable. And yum/apt packages in linux distributions may be out of date.
  • doc: where can i save ENVIRONMENT variables? It's easy to use export TMPDIR='/tmp' temporarily, but any config file i can store it?
  • doc: (ssh) how to use normal user with sudo instead of using root user directly?
  • doc: how to use non-standard ssh port number?
  • doc: -d option is deprecated, but doc doesn't mention this, and the replacement (-vvv).
  • Don't require ssh connection if the target host is localhost? It doesn't make much sense.
  • cdist should print target host name, task name and exist status automatically. currently you have to add a line like echo '[$__target_host] Create file xxx' manually for EACH task/type. Maybe add new attribute --name <text> for ALL types.
  • no error handle. I know we can check exist status with shell ($?), but any better way?
  • Require a new type: __service. Used to start/stop/restart network services. it should be a wrap of service command on CentOS/FreeBSD, and systemctl on systemd enabled Linux distros like CentOS (7)/Debian (8+)/Ubuntu, and rcctl on OpenBSD.
*Created by: iredmail* * [ ] doc: How about encourage user to install cdist with `easy_install`, `pip` from pypi? git version may be not so stable. And yum/apt packages in linux distributions may be out of date. * [ ] doc: where can i save ENVIRONMENT variables? It's easy to use `export TMPDIR='/tmp'` temporarily, but any config file i can store it? * [ ] doc: (ssh) how to use normal user with sudo instead of using root user directly? * [x] doc: how to use non-standard ssh port number? * [ ] doc: `-d` option is deprecated, but doc doesn't mention this, and the replacement (`-vvv`). * [ ] Don't require ssh connection if the target host is localhost? It doesn't make much sense. * [ ] cdist should print target host name, task name and exist status automatically. currently you have to add a line like `echo '[$__target_host] Create file xxx'` manually for EACH task/type. Maybe add new attribute `--name <text>` for ALL types. * [ ] no error handle. I know we can check exist status with shell (`$?`), but any better way? * [ ] Require a new type: `__service`. Used to start/stop/restart network services. it should be a wrap of `service` command on CentOS/FreeBSD, and `systemctl` on systemd enabled Linux distros like CentOS (7)/Debian (8+)/Ubuntu, and `rcctl` on OpenBSD.
ungleich-gitea added the
Stale
label 2021-11-20 15:20:20 +00:00
Author
Owner

closed

closed
Author
Owner

Created by: telmich

@Unterstrichmoepunterstrich Not sure if I understand the request correctly - but cdist uses standard libc parsing, so it actually uses /etc/hosts by default

*Created by: telmich* @Unterstrichmoepunterstrich Not sure if I understand the request correctly - but cdist uses standard libc parsing, so it actually uses /etc/hosts by default
Author
Owner

Created by: Unterstrichmoepunterstrich

Hello,

I have another feature request:

it would be great, when cdist would be able to parse the /etc/hosts.
E.g. you changed a dns entry and now you have to wait, so you make a entry in your hosts file. You can ping the host under the new name but you can't use ssh/cdist.

*Created by: Unterstrichmoepunterstrich* Hello, I have another feature request: it would be great, when cdist would be able to parse the /etc/hosts. E.g. you changed a dns entry and now you have to wait, so you make a entry in your hosts file. You can ping the host under the new name but you can't use ssh/cdist.
Author
Owner

Created by: darko-poljak

@iredmail cdist man page and man page part of html docs in options list mentions that -d is deprecated and that -vvv should be used instead.

*Created by: darko-poljak* @iredmail cdist man page and man page part of html docs in options list mentions that -d is deprecated and that -vvv should be used instead.
Author
Owner

Created by: 4nd3r

isn't there a way to bridge irc and rocket.chat?

matrix has rocket.chat bridges, for example.

*Created by: 4nd3r* isn't there a way to bridge irc and rocket.chat? matrix has rocket.chat bridges, for example.
Author
Owner

Created by: telmich

@iredmail the reason why we moved away from IRC is exactly what happens in IRC: when you are away, we cannot continue the discussion / you don't see the messages that I wrote while you are away

*Created by: telmich* @iredmail the reason why we moved away from IRC is exactly what happens in IRC: when you are away, we cannot continue the discussion / you don't see the messages that I wrote while you are away
Author
Owner

Created by: iredmail

How about use existing irc.freenode.net #cstar channel? My id is "zhb".

*Created by: iredmail* How about use existing irc.freenode.net #cstar channel? My id is "zhb".
Author
Owner

Created by: telmich

@iredmail can I invite you to https://chat.ungleich.ch on channel #cdist for further discussion? Specifically we are debating about the macos problem that you have shown (and is actually pretty nasty)

*Created by: telmich* @iredmail can I invite you to https://chat.ungleich.ch on channel #cdist for further discussion? Specifically we are debating about the macos problem that you have shown (and is actually pretty nasty)
Author
Owner

Created by: iredmail

using cdist straight from git checkout is easy, but I agree that maybe it needs some clarification. but if you are already picking cdist and shell scripting, you should be knowing what are you doing anyway eg how PATH works etc :>

about stability of git master branch - maybe keep all development under different branch (we already have beta branch, lets have next or develop?) and let master always be latest stable?

The point of using pypi edition is user always get the LATEST STABLE release, You can also mention git way (for advanced user or hacker). It's terrible that it doesn't work when user first tries it.

this can be useful if every admin has local user account with auth/sudo logging (with central syslog) so you can have lightweight solution for auditing admin actions, but this solution has some problems and I wouldn't recommend it. or you maintain complex patterns in sudoers file for type execution and... I'm not even sure if it will fly. other than that I don't see other usefulness. YMMV.

So many Amazon EC2 users use only ubuntu user with sudo.

but ssh-config is (almost) so flexible place with all matching and other clever rules etc. reimplementing all this flexibility in cdist seems bit waste of time.

I would suggest don't mess up ~/.ssh/config. This way you have to put ~/.ssh/config in same git repo of your manifest files. With Ansible, i just put all target hosts related ssh info in its inventory file.

*Created by: iredmail* > using cdist straight from git checkout is easy, but I agree that maybe it needs some clarification. but if you are already picking cdist and shell scripting, you should be knowing what are you doing anyway eg how PATH works etc :> > > about stability of git master branch - maybe keep all development under different branch (we already have beta branch, lets have next or develop?) and let master always be latest stable? The point of using pypi edition is user always get the LATEST STABLE release, You can also mention git way (for advanced user or hacker). It's terrible that it doesn't work when user first tries it. > this can be useful if every admin has local user account with auth/sudo logging (with central syslog) so you can have lightweight solution for auditing admin actions, but this solution has some problems and I wouldn't recommend it. or you maintain complex patterns in sudoers file for type execution and... I'm not even sure if it will fly. other than that I don't see other usefulness. YMMV. So many Amazon EC2 users use only `ubuntu` user with sudo. > but ssh-config is (almost) so flexible place with all matching and other clever rules etc. reimplementing all this flexibility in cdist seems bit waste of time. I would suggest don't mess up `~/.ssh/config`. This way you have to put `~/.ssh/config` in same git repo of your manifest files. With Ansible, i just put all target hosts related ssh info in its inventory file.
Author
Owner

Created by: 4nd3r

doc: How about encourage user to install cdisk with easy_install, pip from pypi? git version may be not so stable. And yum/apt packages in linux distributions may be out of date.

using cdist straight from git checkout is easy, but I agree that maybe it needs some clarification. but if you are already picking cdist and shell scripting, you should be knowing what are you doing anyway eg how PATH works etc :>

about stability of git master branch - maybe keep all development under different branch (we already have beta branch, lets have next or develop?) and let master always be latest stable?

doc: (ssh) how to use normal user with sudo instead of using root user directly?

this can be useful if every admin has local user account with auth/sudo logging (with central syslog) so you can have lightweight solution for auditing admin actions, but this solution has some problems and I wouldn't recommend it. or you maintain complex patterns in sudoers file for type execution and... I'm not even sure if it will fly. other than that I don't see other usefulness. YMMV.

cdist should print target host name, task name and exist status automatically.
doc: -d option is deprecated, but doc doesn't mention this, and the replacement (-vvv).

oh really? didn't know that :> and I still find -v vs -vv bit confusing. I would excpect some very light verbosity with -v, like <host> executing <type> and that's it.

Require a new type: __service. Used to start/stop/restart network services. it should be a wrap of service command on CentOS/FreeBSD, and systemctl on systemd enabled Linux distros like CentOS (7)/Debian (8+)/Ubuntu, and rcctl on OpenBSD.

that would be useful writing cross distro/os types.

For example, we can use : as target host.
better not add an entry in ~/.ssh/config for each host i manage.

but ssh-config is (almost) so flexible place with all matching and other clever rules etc. reimplementing all this flexibility in cdist seems bit waste of time.

one thing I would maybe like to see, is ability to define specific ssh-config per inventory tag. for example I have some hosts tagged with "special-rules-for-those-hosts" etc. and then if, for example, .cdist/ssh-config-special-rules-for-those-hosts exists, it will be added to ssh command with -F. but downside here is that multiple -F <configfile> with configs merge isn't supported, so it kinda breaks purpose of tagging. it's a struggle with many hosts, which are easy to tag in cdist, but then I also need extra Match rule in .ssh/config too.

so there can be definitely some improvements, but how? :>

*Created by: 4nd3r* > doc: How about encourage user to install cdisk with easy_install, pip from pypi? git version may be not so stable. And yum/apt packages in linux distributions may be out of date. using `cdist` straight from git checkout is easy, but I agree that maybe it needs some clarification. but if you are already picking `cdist` and shell scripting, you should be knowing what are you doing anyway eg how PATH works etc :> about stability of git master branch - maybe keep all development under different branch (we already have beta branch, lets have next or develop?) and let master always be latest stable? > doc: (ssh) how to use normal user with sudo instead of using root user directly? this can be useful if every admin has local user account with auth/sudo logging (with central syslog) so you can have lightweight solution for auditing admin actions, but this solution has some problems and I wouldn't recommend it. or you maintain complex patterns in sudoers file for type execution and... I'm not even sure if it will fly. other than that I don't see other usefulness. YMMV. > cdist should print target host name, task name and exist status automatically. > doc: -d option is deprecated, but doc doesn't mention this, and the replacement (-vvv). oh really? didn't know that :> and I still find `-v` vs `-vv` bit confusing. I would excpect some very light verbosity with `-v`, like `<host> executing <type>` and that's it. > Require a new type: __service. Used to start/stop/restart network services. it should be a wrap of service command on CentOS/FreeBSD, and systemctl on systemd enabled Linux distros like CentOS (7)/Debian (8+)/Ubuntu, and rcctl on OpenBSD. that would be useful writing cross distro/os types. > For example, we can use <server>:<port> as target host. > better not add an entry in ~/.ssh/config for each host i manage. but ssh-config is (almost) so flexible place with all matching and other clever rules etc. reimplementing all this flexibility in cdist seems bit waste of time. one thing I would maybe like to see, is ability to define specific ssh-config per inventory tag. for example I have some hosts tagged with "special-rules-for-those-hosts" etc. and then if, for example, `.cdist/ssh-config-special-rules-for-those-hosts` exists, it will be added to ssh command with `-F`. but downside here is that multiple `-F <configfile>` with configs merge isn't supported, so it kinda breaks purpose of tagging. it's a struggle with many hosts, which are easy to tag in cdist, but then I also need extra Match rule in `.ssh/config` too. so there can be definitely some improvements, but how? :>
Author
Owner

Created by: iredmail

We need to support more ssh options in a HOSTFILE, these options are so common and we need them for daily work. for example:

  • target host server name/address. This is ok right now since cdist requires one host per line.
  • ssh port number
  • ssh login username
  • the shell used to execute our type

Personally i think the Ansible style inventory file is very good. for example:

[group_name]
u16.mydomain.com ansible_host=172.16.100.138 ansible_port=1234 ansible_user=ubuntu
localhost ansible_connection=local ansible_python_interpreter=/usr/local/bin/python

Those ansible_* variables are officially supported by Ansible, but it's easy to extend by adding your custom variable names.

Of course i don't mean we make cdist an Ansible clone, but this inventory file is much better than cdist one.

*Created by: iredmail* We need to support more ssh options in a HOSTFILE, these options are so common and we need them for daily work. for example: * target host server name/address. This is ok right now since cdist requires one host per line. * ssh port number * ssh login username * the shell used to execute our `type` Personally i think the Ansible style inventory file is very good. for example: ``` [group_name] u16.mydomain.com ansible_host=172.16.100.138 ansible_port=1234 ansible_user=ubuntu localhost ansible_connection=local ansible_python_interpreter=/usr/local/bin/python ``` Those `ansible_*` variables are officially supported by Ansible, but it's easy to extend by adding your custom variable names. Of course i don't mean we make cdist an Ansible clone, but this inventory file is much better than cdist one.
Author
Owner

Created by: telmich

Btw, thanks for opening the issue here - it's a good place to discuss!

*Created by: telmich* Btw, thanks for opening the issue here - it's a good place to discuss!
Author
Owner

Created by: iredmail

I disagree.

I would prefer to do it with just cdist. For example, we can use <server>:<port> as target host. i don't want to touch other config files, better not add an entry in ~/.ssh/config for each host i manage.

*Created by: iredmail* I disagree. I would prefer to do it with just cdist. For example, we can use `<server>:<port>` as target host. i don't want to touch other config files, better not add an entry in `~/.ssh/config` for each host i manage.
Author
Owner

Created by: telmich

non standard port: use ~/.ssh/config - it's not cdist's role to care about that (or in other words: ssh can do it much better)

*Created by: telmich* non standard port: use ~/.ssh/config - it's not cdist's role to care about that (or in other words: ssh can do it much better)
Sign in to join this conversation.
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: ungleich-public/cdist#153
No description provided.