Dynamic setting of TCP window scaling option - tcp

When I am trying to change window scale options, as a root I am able to change the values by doing net.ipv4.tcp_mem=16777000 in /proc/sys/net/. If I have to change this 100 systems its a lot of work. SO, how can I dynamically change this value instead of manually changing it in every system?

You can try running a script to affect it all the machines .
Similar to the below :
USERNAME=someUser HOSTS="host1 host2 host3" SCRIPT="pwd; ls" for
HOSTNAME in ${HOSTS} ; do
ssh -l ${USERNAME} ${HOSTNAME} "${SCRIPT}" done

Related

In tmux, how can I move the current window in the next/previous session without specifying its name or index?

I'm currently using tmux 3.1c; I'd like to bind two keys in order to move the current window in the next/previous session. I want that the window is moved regardless the current session's name/index. The basic idea is that:
if I press e.g. C-b + some <key1>, the current window is moved in the session following the current one, without giving any further input; the window should be moved in the last position of this next session;
if I press e.g. C-b + some <key2> the current window is moved in the session before the current one, without giving any further input; the window should be moved in the last position of this previous session;
On the man pages I found some tokens which act as aliases in order to refer to windows/panes, but no tokens for sessions. I found some interesting examples also here, but no one pointed me to the result I wanted to achieve.
My guess is that in my .tmux.conf I need to set something like
bind-key <key1> move-window -t <target_for_next_session>
bind-key <key2> move-window -t <target_for_previous_session>
(and maybe target the current window somehow too for -s option). I tried to play around with those targets but with no luck. My main guess is that I need to combine the session_id variable in the FORMATS section with the -t option from bind-key, with some +1/-1 increment.
Unfortunately answers for this question always refer to session names/indexes, which are something I don't want to specify.
Thanks in advance!

How to change the hard coded port to their environment names in deployement.toml?

I am using some offset as I am running 2 nodes in one Virtual machine but looks like some port like (5672,9611,9711) are directly present so I suppose offset wont be applied to this ports and i will have to change it manually to get it work ... is their any way to optimise this so that when I apply offset it will change all the ports automatically in run time and I don't have to worry about to change it manually ?
You can add the offset to every port by adding the following configuration to the deployment.toml
[server]
offset = ""
You can refer the following documentation for more information on this
https://is.docs.wso2.com/en/latest/references/default-ports-of-wso2-products/

sendkey to active tmux window

I have a tmux session called test with several windows, one for each test file. I have another tmux session with vim and the tmuxify plugin. When I tap <f8>, my .vimrc file is programmed to send the <f7> key to the the left pane in window #0 like so:
nmap <buffer> <F8> :execute "silent !tmux send-keys -t test:0.left 'F7'" <bar>:redraw!<CR>
<f7> triggers the test to be run. Works well.
However, notice the test:0.left bit. I have window #0 hardcoded in there. If I want to run the tests in window #7, for example, I first have to swap it with window #0 and then run the test.
What I'd rather do is just send the <f7> key to whatever window in the test session is currently open.
Is there a way to do this?
I consulted ye olde manual. Solution:
test:.left
Leaving the window blank defaults to the current window.

Auto decrypt multiple LUKS Devices with Mandos

I played around with Mandos to automatically open an encrypted root device. I wanted to setup an encrypted btrfs raid 1 (sda1 and sdb1: LUKS). The first device is decrypted correctlly, but the second will noch be opened. Is there a way to do this?
As of Debian Stretch, it just works (tm). Both devices should be listed in /etc/crypttab and the btrfs raid1 should be setup. Then install mandos. Confirmed working on Debian Stretch 9.5.
The solution is relative simple:
Instead of adding your disks to /etc/crypttab, add them directly to /etc/initramfs-tools/conf.d/cryptroot and don't forget the keyscript part (keyscript=/lib/mandos/plugin-runner).
/etc/initramfs-tools/conf.d/cryptroot:
target=sda2_crypt,source=UUID=0f47884b-fb02-478e-b4dd-c594cf1cbbf1,key=none,rootdev,discard,keyscript=/lib/mandos/plugin-runner
target=sdb2_crypt,source=UUID=65f16e28-5b74-4b1f-9f81-01729244ac2c,key=none,rootdev,discard,keyscript=/lib/mandos/plugin-runner
To be sure the complete cryptsetup stack is compiled correctly into the initramfs, add a dummy device to /etc/crypttab. Take care to add noauto, otherwise it will try to unlock the device on startup and will fail.
/etc/crypttab:
dummy_device UUID=087963da-63bb-439b-bb5a-15e712d02a29 none noauto,luks,discard
I would suggest that you on the root file system (I would suggest in /etc/keys) have a file containing the password to any other disks, and enter that file name in the third field in /etc/crypttab.

How to suppress -mmax value exceeded.Automatically increasing from old value to new value.<5409>?

in prokb,its mentioned
In 10.0B02 and above, the client session startup parameter -noincrwarn was reintroduced
to allow the selective suppression of the above four warning messages ONLY. Since the
execution of the 4GL statement: SESSION:SUPPRESS-WARNINGS = YES. suppresses ALL warning
messages during the session.
Where and how could i set i this startup parameter -noincrwarn to suppress this warning
message?
"SESSION:SUPPRESS-WARNINGS = YES." doesn't do much of anything useful. Or at least it didn't the last time I tested it.
The -mmax warning is harmless. It is a "soft" limit that is dynamically allocated and expanded as needed. You can ignore it. Or if the .lg file entries really bother you, you can simply increase it to a reasonable value. I routinely set it to 8192 for character sessions, 32768 for Windows. The default, as JensD says, is ludicrously low.
Startup parameters, such as -noincwarn, can set in a number of ways:
1) Via the command line. If your application starts via a script it will eventually invoke progress via "pro", "mpro", progress, prowin32, proapsv or some other executable (you can potentially link your own objects and create custom executables...) The command line that invokes Progress will have a number of parameters. You could add it there. Windows example:
#echo off
set DLC=\Progress\OpenEdge
%DLC%\bin\prowin32 -db mydb -p start.p -noincwarn
(On windows it is also common for the shortcut properties to have the command line listed.)
2) In a "pf" file. "PF" files are parameter files. They contain a list of parameters in a text file. This makes it easy to share and manage parameters between many scripts. To use a parameter file you need at least one -pf filename.pf parameter. Unix example:
#!/bin/sh
DLC=/usr/dlc
export DLC
${DLC}/bin/_progres -db mydb -pf mypf.pf
Where "mypf.pf" might contain:
# mypf.pf
-p start.p
-noincwarn
There is a global .pf file in the Progress install directory called startup.pf. You could also add it to that.
3) In an "ini file". Sort of like the pf file but more complicated. Indicated by the -ininame startup parameter. Can also be influenced by registry keys.
Why not removing or trying another value for -mmax? If you're moving from an old version of Progress it might be that -mmax is set very low.
The Maximum Memory (-mmax) client session parameter specifies the maximum amount of memory allocated for r-code segments, in kilobytes.
Source: http://knowledgebase.progress.com/articles/Article/P11351?popup=true
Large memory consumption might depend on complicated business logic (things like very large and or deeply nested procedures) so you might consider looking into that.
However a much easier fix would be to increase the value. Default is 3096, meaning each client "only" gets 3 Mb for this. Not a very large amount with today's standards.
If you really only want to suppress the message. Set -noincrwarn in your client side startup script (or corresponding .pf-file/startup.pf).
Hosting a WPF element (windows Presentation Foundation) in an OpenEdge application can cause application to crash if any message cover the window. It is also the case of this message.
In order to suppress any messages including message 5409 ()
According to article "HOW TO SUPPRESS WARNING MESSAGES (5407),(5408),(5409),(5410) FROM DISPLAYING ON CLIENT SCREENS."
I used with expected results SESSION:SUPPRESS-WARNINGS = YES. As the first line in the starting procedure of the aplication.
Using -noincrwarn as the session startup parameter had no effect in Open Edge 11.4
Supress openedge messages:
http://knowledgebase.progress.com/articles/Article/P79795?popup=true
.NET related error for OpenEdge-WPF hibrid application "Invisible or disabled control cannot be activated"
https://social.msdn.microsoft.com/Forums/windows/en-US/e8cf6431-2a59-4335-8b36-fc8f35083823/invisible-or-disabled-control-cannot-be-activated?forum=winforms

Resources