I' trying to build a tmuxinator with multiple windows and in one of them i`d like to build 2 panes:
name: bigbang-server
root: ~/projects/bigbang
windows:
- CORE:
- ...
- CONSOLE:
- ...
- FUND_TRANSACTIONS:
- ...
- CLIENT_POSITIONS:
pre_window: cd ~/projects/bigbang_services/
panes:
server:
- env PORT=3002 rails server
sidekiq:
- bundle exec sidekiq -C config/sidekiq.yml
it doesnt run any of my last window commands, here its debug:
# Window "CLIENT_POSITIONS"
tmux select-window -t 1
tmux select-pane -t 0
if [ -z "$TMUX" ]; then
tmux -u attach-session -t bigbang-server
else
tmux -u switch-client -t bigbang-server
fi
It seems there are some points to fix.
pre_window: should be top-level, not under windows:.
Any hash element (like name:) is not allowed under the pane:.
Like this.
name: bigbang-server
root: ~/projects/bigbang
pre_window: cd ~/projects/bigbang_services/
windows:
- CORE:
- ...
- CONSOLE:
- ...
- FUND_TRANSACTIONS:
- ...
- CLIENT_POSITIONS:
panes:
- env PORT=3002 rails server
- bundle exec sidekiq -C config/sidekiq.yml
The way you wrote the commands for the panes in that particular window is wrong.
It should have been something like this:
windows:
- CLIENT_POSTIONS:
panes:
- cd ~/projects/bigbang_services/
- env PORT=3002 rails server
- bundle exec sidekiq -C config/sidekiq.yml
This creates 2 horizontal splits first then splits the first one vertically.
To use horizontal or vertical splits throughout the window,
use main-horizontal or main-vertical.
Like this:
windows:
- CLIENT_POSTIONS:
layout: main-vertical # or main-horizontal
panes:
- cd ~/projects/bigbang_services/
- env PORT=3002 rails server
- bundle exec sidekiq -C config/sidekiq.yml
Related
I have a .tmuxinator.yml which looks like this:
pre_window:
windows:
- workspace:
layout: even-vertical
panes:
- health:
- printf '\033]2;%s\033\\' 'healthcheck'
- cd dev-env
- clear
- work:
- printf '\033]2;%s\033\\' 'workspace'
- clear
- api:
layout: even-vertical
panes:
- database:
- printf '\033]2;%s\033\\' 'api-database'
- cd api
- docker-compose up
- server:
- printf '\033]2;%s\033\\' 'api'
- cd api
- yarn watch
- workspace:
- printf '\033]2;%s\033\\' 'api-workspace'
- cd api
- clear
This used to work but now it only runs the first pane commands correctly which means it just doesn't call the commands after the printf ... statements for any other than the first one in each window.
Update: removing the `printf ...' statements seems to fix it but I would like to keep them.
I'm using
tmux 3.2a
tmuxinator 3.0.1
macOS 12.0.1 (Monterey - the problem is not caused by Monterey as the problem did exist before)
I've double checked the line endings using cat -e .tmuxinator.yml.
How do you set a unique title on each pane in a tmuxinator session?
I'm trying to run multiple panes to show the output from htop being run through ssh to different servers. My configuration looks like:
project_name: Server Monitor
windows:
- servers:
layout: tiled
panes:
- ssh -t -i mykey.pem user#server1 htop
- ssh -t -i mykey.pem user#server2 htop
- ssh -t -i mykey.pem user#server3 htop
When I launch this with tmuxinator local, it runs the commands just fine and I see the output from htop. However, the panes all look the same and the SSH title isn't shown, making it nearly impossible to tell which pane corresponds to which server.
How do I change my configuration so that a unique title is shown on each pane?
This example shows that this feature is supported in the underlying tmux, but I'm not sure how to access this through tmuxinator.
What you need to do is first enable pane status in your .tmux.conf with the lines:
set -g pane-border-format "#{pane_index} #{pane_title}"
set -g pane-border-status bottom
Then add to your tmuxinator config a printf command that will send the appropriate escape sequence to dynamically set the pane title. You will have 2 commands now per pane, so you need to add another level of indentation with a name.
project_name: Server Monitor
windows:
- servers:
layout: tiled
panes:
- p1:
- printf '\033]2;%s\033\\' 'server1'
- ssh -t -i mykey.pem user#server1 htop
- p2:
- printf '\033]2;%s\033\\' 'server2'
- ssh -t -i mykey.pem user#server2 htop
- p3:
- printf '\033]2;%s\033\\' 'server3'
- ssh -t -i mykey.pem user#server3 htop
You need at least tmux 2.3 to have pane titles shown in the borders.
For anyone else who comes across this and:
Doesn't want to change their layout
Has a problem parsing the structure in Meuh's answer (I was getting a undefined method shellescape for #<Array error.
You still need to add these to your .tmux.conf:
set -g pane-border-format "#{pane_index} #{pane_title}"
set -g pane-border-status bottom
You can just add a ; before the ssh command and do this:
name: myBoxes
root: ~/
windows:
- hosts:
layout: tiled
panes:
- printf '\033]2;%s\033\\' 'role_storage_v45 : hostname2.net'; ssh 10.20.30.1
- printf '\033]2;%s\033\\' 'role_dns_v15 : hostname1.net'; ssh 10.20.30.2
I'm getting my feet wet with SaltStack. I've made my first state (a Vim installer with a static configuration) and I'm working on my second one.
Unfortunately, there isn't an Ubuntu package for the application I'd like my state to install. I will have to build the application myself. Is there a "best practice" for doing "configure-make-install" type installations with Salt? Or should I just use cmd?
In particular, if I was doing it by hand, I would do something along the lines of:
wget -c http://example.com/foo-3.4.3.tar.gz
tar xzf foo-3.4.3.tar.gz
cd foo-3.4.3
./configure --prefix=$PREFIX && make && make install
There are state modules to abstract the first two lines, if you wish.
file.managed: http://docs.saltstack.com/ref/states/all/salt.states.file.html
archive.extracted: http://docs.saltstack.com/ref/states/all/salt.states.archive.html
But you could also just run the commands on the target minion(s).
install-foo:
cmd.run:
- name: |
cd /tmp
wget -c http://example.com/foo-3.4.3.tar.gz
tar xzf foo-3.4.3.tar.gz
cd foo-3.4.3
./configure --prefix=/usr/local
make
make install
- cwd: /tmp
- shell: /bin/bash
- timeout: 300
- unless: test -x /usr/local/bin/foo
Just make sure to include an unless argument to make the script idempotent.
Alternatively, distribute a bash script to the minion and execute. See:
How can I execute multiple commands using Salt Stack?
As for best practice? I would recommend using fpm to create a .deb or .rpm package and install that. At the very least, copy that tarball to the salt master and don't rely on external resources to be there three years from now.
Let's assume foo-3.4.3.tar.gz is checked into GitHub. Here is an approach that you might pursue in your state file:
git:
pkg.installed
https://github.com/nomen/foo.git:
git.latest:
- rev: master
- target: /tmp/foo
- user: nomen
- require:
- pkg: git
foo_deployed:
cmd.run:
- cwd: /tmp/foo
- user: nomen
- name: |
./configure --prefix=/usr/local
make
make install
- require:
- git: https://github.com/nomen/foo.git
Your configuration prefix location could be passed as a salt pillar. If the build process is more complicated, you may consider writing a custom state.
I recently switched from screen to tmux/powerline/tmuxinator
As shown below, there is a big unused space between the window and status bar.
What could be causing it?
.tmux.conf
set -g prefix C-t
unbind C-b
bind C-t send-prefix
set -g status-keys emacs
setw -g mod-keys emacs
set -g status-position bottom
# status bar
set-option -g status-utf8 on
# status bar
# windows
bind-key C-t last-window
# focus on first window#
select-window -t 0
source ~/.local/lib/python2.7/site-packages/powerline/bindings/tmux/powerline.conf
and tmuxinator
# ~/.tmuxinator/zibann.yml
name: zibann
root: ~/Documents/zibann/
# Optional tmux socket
# socket_name: foo
# Runs before everything. Use it to start daemons etc.
# pre: sudo /etc/rc.d/mysqld start
# Runs in each window and pane before window/pane specific commands. Useful for setting up interpreter versions.
# pre_window: rbenv shell 2.0.0-p247
# Pass command line options to tmux. Useful for specifying a different tmux.conf.
# tmux_options: -f ~/.tmux.mac.conf
# Change the command to call tmux. This can be used by derivatives/wrappers like byobu.
# tmux_command: byobu
windows:
- root: ls -l
- emacs: workon zibann && cd momsite && emacs
- cmd: workon zibann && cd momsite
- ipdb: workon zibann && cd momsite && emacs
- dbshell: workon zibann && cd momsite && python manage.py dbshell
- logs:
layout: main-vertical
panes:
- tail -f momsite/momsite/log/celeryd_error.log
- tail -f momsite/momsite/log/celerybeat_error.log
- tail -f momsite/momsite/log/uwsgi_out.log
- tail -f /var/log/nginx/error.log
- supervisor: workon zibann && cd momsite # && python manage.py supervisor --config-file=momsite/conf/supervisord.conf
C-b, D
and detached one of the clients and volla!
(So there must be one and only one client attached at one time I guess)
I tried to add:
mypack:
pkg:
- installed
- pkgs:
- mercurial
- git
cmd.run:
- name: 'mkdir -p /opt/mypack'
cmd.run: 'hg pull -u -R /opt/mypack || hg clone -R /opt https://...'
cmd.run: 'ln -s /opt/mypack/etc/init.d/xxx /etc/init.d/xxx'
But for some reason this the state seems to execute/install but the commands are not executed, or at least not all of them.
I need a solution to run multiple commands and to fail the deployment if any of these fails.
I know that I could write a bash script and include this bash script, but I was looking for a solution that would work with only the YAML file.
You want this:
cmd-test:
cmd.run:
- name: |
mkdir /tmp/foo
chown dan /tmp/foo
chgrp www-data /tmp/foo
chmod 2751 /tmp/foo
touch /tmp/foo/bar
Or this, which I would prefer, where the script is downloaded from the master:
cmd-test:
cmd.script:
- source: salt://foo/bar.sh
- cwd: /where/to/run
- user: fred
In addition to the above (better) suggestions, you can do this:
cmd-test:
cmd.run:
- names:
- mkdir -p /opt/mypack
- hg pull -u -R /opt/mypack || hg clone -R /opt https://...
- ln -s /opt/mypack/etc/init.d/xxx /etc/init.d/xxx
For reasons I don't understand yet (I'm a Salt novice), the names are iterated in reverse order, so the commands are executed backwards.
You can do as Dan pointed out, using the pipe or a cmd.script state. But it should be noted that you have some syntax problems in your original post. Each new state needs a name arg, you can't just put the command after the colon:
mypack:
pkg:
- installed
- pkgs:
- mercurial
- git
cmd.run:
- name: 'my first command'
cmd.run:
- name: 'my second command'
However, that actually may fail as well, because I don't think you can put multiple of the same state underneath a single ID. So you may have to split them out like this:
first:
cmd.run:
- name: 'my first command'
second:
cmd.run:
- name: 'my second command'
As one of the users pointed out above, this works in proper order (salt 3000.2)
install_borg:
cmd.run:
- names:
- cd /tmp
- wget https://github.com/borgbackup/borg/releases/download/1.1.15/borg-linux64
- mv borg-linux64 /usr/local/bin/borg
- chmod u+x /usr/local/bin/borg
- chown root:root /usr/local/bin/borg
- ln -s /usr/local/bin/borg /usr/bin/borg
- unless: test -f /usr/bin/borg