4 ms·

> but you have an agent anyway By agent, I meant something more narrow: a prerequisite that must be installed on a server before it works. In that sense, the a

> but you have an agent anyway By agent, I meant something more narrow: a prerequisite that must be installed on a server before it works. In that sense, the agent here is sshd, but that can be presumed to always exist. > so once you start to need to configure it, you can break all the things at the same time. Do you mean if the script updates sshd configuration? > Oh, and you just dropped proper configuration management. Now you need to add a task queue (another thing that can break and overflow and what not) to re-send configuration commands when some server is down I'm not sure what you mean, can you please elaborate on a use case of a task queue? Thanks for the comments!

schizoidboy 10y ago
> I'm not sure what you mean, can you please elaborate on a use case of a task queue? Answering my own question by re-reading your comment: I'm not familiar with systems automatically re-trying commands. What if there is some fatal error on the server? It seems like this is something that requires a human, not a task queue. Relatedly, if the system has the `caller` built-in, when there's an error, a stack trace is dumped, including the line number of the failing cube for someone to quickly jump to the failing line in the script. With that said, a retry mechanism could be built-in if it's a big use case.
- dozzie 10y ago
  >> so once you start to need to configure it, you can break all the things at the same time. > Do you mean if the script updates sshd configuration? If you ask this question, it means you've probably never configured SSH in bigger environments, because you don't imagine how easy is to accidentally cut off your access. User's public key disappears, user's shell changes or becomes un-executable, user doesn't get mentioned in AllowUsers and/or AllowGroups, user's home gets unreadable, and plenty other failure modes. >> I'm not sure what you mean, can you please elaborate on a use case of a task queue? > Answering my own question by re-reading your comment: I'm not familiar with systems automatically re-trying commands. What if there is some fatal error on the server? It seems like this is something that requires a human, not a task queue. You actually have provided me another important point: how to tell that the command reached its destination server, but failed there? This is vastly different case than when a command didn't get through to the server, so it can be safely re-sent. (And I was talking about the latter case.) > With that said, a retry mechanism could be built-in if it's a big use case. But now you have a queue which needs to be managed and that also can break. This is not an improvement. Setup with a dedicated agent that works in "pull" mode (instead of one that was not designed for this task, but just happened to be already installed) doesn't have the problem that needs solving with queue in the first place.
  - schizoidboy 10y ago
    First, I just want to say that I appreciate this conversation and debate. It's making me think hard about certain concepts, so thank you. > If you ask this question, it means you've probably never configured SSH in bigger environments, because you don't imagine how easy is to accidentally cut off your access. Many moons ago, I was mucking with sshd configuration, and locked myself out. It was the first and only time I ever had to truly hack - my own system. The system had a Wordpress installation which, at least back then, allowed you to modify the PHP code through the web console. I knew I had gcc on the box, so I found a NULL-dereference root escalation exploit for my kernel version, jammed a bunch of C code into a php system call, and step by step, escalated, and then overwrote my ssh config (all through escaped C code in PHP!). It was fun. So I totally hear ya, updating sshd configuration can be disastrous, and it's certainly required in certain situations. Posixcube is certainly not ready for massive enterprise usage, but I don't see why it couldn't be. For this particular point, it seems that no matter what technology you're using, SSH can always get mucked up, and I see no inherent reason why shell scripts are worse. > You actually have provided me another important point: how to tell that the command reached its destination server, but failed there? This is vastly different case than when a command didn't get through to the server, so it can be safely re-sent. (And I was talking about the latter case.) The way this is handled now is that all cube_* APIs check all return codes and if non-zero, they print the full stack and `exit $code` which is passed back through SSH into the client and reported and the script stops. In the latter case of safely re-sending a command that didn't even get to the server, I don't think that's much of an issue here, because posixcube doesn't execute one command at a time (since the overhead of re-establishing the SSH connection would be massive), but actually generates a shell script on the fly (cube_exec.sh) which has all the commands you want to execute, uploads that as well as all of the cubes, and then executes cube_exec.sh on the other side. > But now you have a queue which needs to be managed and that also can break. This is not an improvement. Setup with a dedicated agent that works in "pull" mode (instead of one that was not designed for this task, but just happened to be already installed) doesn't have the problem that needs solving with queue in the first place. Are you talking about a use case where an administrator is not monitoring a deployment (i.e. fire and forget)?
    - 10y ago

schizoidboy 10y ago

> I'm not sure what you mean, can you please elaborate on a use case of a task queue? Answering my own question by re-reading your comment: I'm not familiar with systems automatically re-trying commands. What if there is some fatal error on the server? It seems like this is something that requires a human, not a task queue. Relatedly, if the system has the `caller` built-in, when there's an error, a stack trace is dumped, including the line number of the failing cube for someone to quickly jump to the failing line in the script. With that said, a retry mechanism could be built-in if it's a big use case.

dozzie 10y ago
>> so once you start to need to configure it, you can break all the things at the same time. > Do you mean if the script updates sshd configuration? If you ask this question, it means you've probably never configured SSH in bigger environments, because you don't imagine how easy is to accidentally cut off your access. User's public key disappears, user's shell changes or becomes un-executable, user doesn't get mentioned in AllowUsers and/or AllowGroups, user's home gets unreadable, and plenty other failure modes. >> I'm not sure what you mean, can you please elaborate on a use case of a task queue? > Answering my own question by re-reading your comment: I'm not familiar with systems automatically re-trying commands. What if there is some fatal error on the server? It seems like this is something that requires a human, not a task queue. You actually have provided me another important point: how to tell that the command reached its destination server, but failed there? This is vastly different case than when a command didn't get through to the server, so it can be safely re-sent. (And I was talking about the latter case.) > With that said, a retry mechanism could be built-in if it's a big use case. But now you have a queue which needs to be managed and that also can break. This is not an improvement. Setup with a dedicated agent that works in "pull" mode (instead of one that was not designed for this task, but just happened to be already installed) doesn't have the problem that needs solving with queue in the first place.
- schizoidboy 10y ago
  First, I just want to say that I appreciate this conversation and debate. It's making me think hard about certain concepts, so thank you. > If you ask this question, it means you've probably never configured SSH in bigger environments, because you don't imagine how easy is to accidentally cut off your access. Many moons ago, I was mucking with sshd configuration, and locked myself out. It was the first and only time I ever had to truly hack - my own system. The system had a Wordpress installation which, at least back then, allowed you to modify the PHP code through the web console. I knew I had gcc on the box, so I found a NULL-dereference root escalation exploit for my kernel version, jammed a bunch of C code into a php system call, and step by step, escalated, and then overwrote my ssh config (all through escaped C code in PHP!). It was fun. So I totally hear ya, updating sshd configuration can be disastrous, and it's certainly required in certain situations. Posixcube is certainly not ready for massive enterprise usage, but I don't see why it couldn't be. For this particular point, it seems that no matter what technology you're using, SSH can always get mucked up, and I see no inherent reason why shell scripts are worse. > You actually have provided me another important point: how to tell that the command reached its destination server, but failed there? This is vastly different case than when a command didn't get through to the server, so it can be safely re-sent. (And I was talking about the latter case.) The way this is handled now is that all cube_* APIs check all return codes and if non-zero, they print the full stack and `exit $code` which is passed back through SSH into the client and reported and the script stops. In the latter case of safely re-sending a command that didn't even get to the server, I don't think that's much of an issue here, because posixcube doesn't execute one command at a time (since the overhead of re-establishing the SSH connection would be massive), but actually generates a shell script on the fly (cube_exec.sh) which has all the commands you want to execute, uploads that as well as all of the cubes, and then executes cube_exec.sh on the other side. > But now you have a queue which needs to be managed and that also can break. This is not an improvement. Setup with a dedicated agent that works in "pull" mode (instead of one that was not designed for this task, but just happened to be already installed) doesn't have the problem that needs solving with queue in the first place. Are you talking about a use case where an administrator is not monitoring a deployment (i.e. fire and forget)?
  - 10y ago