Is there an "opposite" of asg_cp2blades?

[David_Kozinn]

On SP systems (e.g., 61000/41000) asg_cp2blades will allow you to copy a file from the current blade to any or all blades. I've been running some tcpdumps across all blades and the files are saving into /tmp. I want to bring them back to the SMO with modification to the filenames to indicate where it was pulled from, so this is sort of the opposite of what asg_cp2blades does. (Sort of: asg_cp2blades doesn't change the filename, which makes sense for what it does).

For my specific case I know what the filename is, so what I've been doing is to run this from the SMO:

g_all 'scp /tmp/capturefile0 192.0.2.1:/tmp/capturefile0.$HOSTNAME'

192.0.2.1 is the IP of the SMO that I'm running from, and /tmp/capturefile0 is the actual name of the captured file.

This works but it seems like perhaps there's a better way to do this. If I can help it, I don't want to put any executables on the other blades, though a local shell script would be OK.

Before I re-invent the wheel, does anyone have something that already does this?

Thanks.

[Peter_Hoelsken]

Have you ever tried the following?

tcpdump –mcap –w /tmp/capture

See also: Multi-blade capture (tcpdump âmcap -view)

[David_Kozinn]

Thanks Peter, I wasn't aware of that (learn something new every day). I'm testing that now and because it's going to run for a long time, I want to see if the ability to create multiple logs (using the -C and -W options) works properly with this, since I obviously don't want the capture files to grow without bounds.

One small correction: It's actually g_tcpdump -mcap -w /tmp/capture, not regular tcpdump.

Thanks for the solution to this specific problem, though I'm still curious to know if there's a more general solution to the "fetch a specific file from all blades" problem.

[David_Kozinn]

I've run into an issue which I'll probably bounce off support, but it seems that if I leave the -mcap tcpdump running at some point it acts as though I've typed control-C to stop it even though I haven't. I've got it running in an ssh window with TMOUT set to 0 so the session doesn't time out. I have not actually seen it stop (since it's in an RDP window which is normally behind other windows) but at some point when I pull it to the top I see that it has apparently cleanly stopped and consolidated the dumps.

[Alexander_Wilke]

Helpful command. Professional services did not tell us this command when we asked for a solution.

Unfortunately after copying the files from alle blades to the local blade the scrip does not delete the captures on the remote blades.

Regards

[David_Kozinn]

Apparently the -mcap feature hasn't been officially available since 2015 and from what I heard from our engineer they said that if we wanted the feature we'd have to submit an RFE.

Alexander Wilke‌ What I've been doing to clean up is running something like this from the SMO: 

g_all "rm /tmp/capturefile*"

after I've grabbed all the files and gzipped them.

[Alexander_Wilke]

Hi,

it would be absoloutly OK for me if they told me that there is an unsupported feature at the moment, if we like it as an official version we should submit an RfE then we did it. But not telling anything when talking with professional services and talking with Shay Naveh - chief developer of scaleable plattform - this is not what I would expect from "my vendor".

using the "g_all" command is fine and I use it but as the script automatically copies the files it could also automatically delete the files with the proper names.

I already mailed my local SE and will do the next steps (RfE) with him.

Thanks!