[Closed] Linux help s'il vous plait. Installing multiple versions of packages.

As an aside, for regular readers, this was the endgoal from my earlier thread:
http://singletrackmag.com/forum/topic/building-a-custom-linux-live-usb

Ooh, I like iperf......don't suppose they install into user space solely?

In which case, would creating a separate user, logging into that, install either/or version, do the job?

What I quite liked about the Win version was that there was no need to install; just a binary.

I did wonder about that, whether it could install into /usr or something, but it's beyond my knowledge (to be fair though, when I started this it was all beyond my knowledge, I've learned quite a bit in the seven months since I started this project).

Windows does something creative with the network connection I'm told, some sort of "optimisation" or other which skews the results. Exactly what that is I don't know, I've not looked into it. Maybe it's something that can be tweaked in the adapter settings, but I don't know (or want to know) enough about iperf to be able to troubleshoot it further. I know more about Windows but less about networking than most of our network engineers so I've (unusually) taken what they've told me at face value for once.

I've used it on W2K clients, XP clients.....no problems that I've found. 'Optimisation', they tell you? Odd. I think that there may be a strange windowing/buffering thing going on in 7....not too sure TBH.

I've been trying to find out the dependencies and install paths for the Ubuntu/Deb package for you, still looking.

If you're building the packages yourself I'd suggest changing the prefix for each build so they don't trample each other: into /opt/iperf2 and /opt/iperf3 instead of /usr.

'Optimisation', they tell you? Odd. I think that there may be a strange windowing/buffering thing going on in 7....not too sure TBH.

Could be that. I don't know to be honest, my default is to question everything I'm told as "fact" by other engineers, but I couldn't be bothered to argue with this one.

If you're building the packages yourself I'd suggest changing the prefix for each build so they don't trample each other: into /opt/iperf2 and /opt/iperf3 instead of /usr.

At what point do you do that? This is the first time I've ever done anything like this.

The procedure I've been following is to unpack the tarball, run configure then make, then use checkinstall to spit out a .deb package, but I don't really understand what each step really does beyond blindly following instructions on the Internet.

As far as I can see, configure seems to be applying platform-specific settings, then make actually compiles the code. Is it a setting within make or do I need to start hacking the text files in the original tarball first? Or am I talking pish?

./configure --prefix=/opt/iperf2

I was just going to say look at the options for configure. Allows you to put prefix and specify install location.

Awesome. I'll have a play, cheers guys.

Configure is part of autoconf it writes your make file
https://www.gnu.org/software/autoconf/manual/autoconf.html#Top

Never used it as a developer only as a end user.

Right. Ripped out all the previous versions. Installed iperf from the repository, then installed iperf3 from the freshly configured .deb. Now I'm getting,

# iperf
bash: /usr/bin/iperf: No such file or directory
# iperf3
bash: /usr/local/bin/iperf: No such file or directory

What do you get from:

[code]
which iperf
which iperf3
[/code]

The .deb has installed correctly into /opt/iperf3 it seems, so presumably I could fix that with an alias though that feels clunky to me.

Interestingly, apt-get remove iperf removes my custom iperf3 package, not the original iperf, so presumably it's still thinking that it's an upgrade of iperf 2 rather than a separate thing.

...and what do you get for that with a clean install of either

Also what happens if you re-install iperf?

[quote=Cougar ]Interestingly, apt-get remove iperf removes my custom iperf3 package

From /opt/iperf3? Very curious.

Install iperf from repository with apt-get install:

# which iperf
/usr/bin/iperf

(which iperf3 returns nothing, which is what I expected.)

Next, dpkg -i iperf_3.1.3.M-1_amd64.deb

Both which iperf and which iperf3 now return nothing.

So is /usr/bin/iperf still there after installing the deb? And where is the iperf3 binary installing to?

BTW what tags are you using to get your code blocks a different shade, "[code]" doesn't see to do that

From /opt/iperf3? Very curious.

Yes.

Also what happens if you re-install iperf?

If I install the .deb and then apt-get iperf, it tells me iperf is already the newest version (3.1.3.M-1).

The 'M' is there because I was prompted to enter a version number by, uh, checkinstall I think, I gave it 3.1.3.M so I could readily tell it apart from the official 3.1.3 binaries.

[quote=Cougar ]If I install the .deb and then apt-get iperf, it tells me iperf is already the newest version (3.1.3.M-1).

Ah, you're screwed then 🙂

I'm thinking there's some force option with apt-get though...

Can you use Docker and just have different containers for each version?

...OK so I've plugged in an RPi as it's the easiest way for me to get debian running (I suspect instructions for Fedora might not help much!)

Try: dpkg --listfiles iperf

(worth trying before and after installing iperf3, and for iperf3)

So is /usr/bin/iperf still there after installing the deb? And where is the iperf3 binary installing to?

No.
The /opt folder.

There's something funky going on here. I just spotted, installing the .deb says, Unpacking iperf (3.1.3.M-1) over (2.0.5+dfsgl-2) ... This is the crux I think, it thinks it's the same thing.

The thing is, I'm 99% sure I didn't have this problem with the official binaries. I could have the repository and an official .deb of iperf3 running concurrently. Though I've just installed iperf3 and iperf from the repositories, which reports /usr/bin/iperf and /usr/bin/iperf3 respectively, but typing iperf3 to run it fails as it's now looking in /usr/local/bin/iperf3... 😯

I've clearly bollocksed something here with repeatedly remaking / reinstalling. I think what I might do here is rip out the source code directory and start again from scratch with a fresh copy of the source.

I've not used iperf but can you not just use make install instead of creating a .deb (I'm assuming there's a makefile...)? Ok you won't be able to use a package manager to manage it but if you set the prefix for each then it should install both. You might have to softlink the binary one of them under a different alias though?

I've not used iperf but can you not just use make install instead of creating a .deb

That's what I did originally. The problem is, I need to roll this out to two dozen engineers. It's a lot simpler to say "run the attached file on this email" than it is to have them all download a 5Gb disk image of the entire pendrive every time I make a minor change.

Plus, make install seemed... messy.

Anyway, I'm going home, I'll pick this up in the morning. Thanks for your help this far guys.

Get rid of everything that debian might have gone and put there.

sudo apt-get install iperf- iperf3- iperf2-

At this point which iperf should report nothing.

Now grab the actual source code, and build that via configure in the time-honoured fashion.

tar xvf iperf-x.y.z.tar.gz
cd iperf-x.y.z
./configure --prefix=/opt/whatever
make -j
sudo make install

Hang on, just remembered something from building PXE boot systems. Create a completely separate file structure and chroot into it. Much easier than debugging the deb!

Is that something they'll have to do each time they want to switch between?

Our engineers are of varying ability outside of their field. Having to switch between filesystems would be unworkable I think.

make -j

What's -j ?

sudo make install

I don't really want to be venturing outside of the package manager for portability / compatibility / simplicity if I can help it.

-j = multicore support, so can be used to speed up compilations, although it's really easy to kill a box when you give it a large value 😉

Solutions such as Docker (or Vagrant) are nice - essentially mean you don't have to care so much about portability, and would provide an easy way to spin up isolated environments. There is some overhead though, but probably wouldn't make much difference (at least if you use these environments to run both iperf / iperf3 tests).

They might be overkill though - if the release binaries aren't available, you could try building from source statically, but you said you wanted to make use of the package manager, so that doesn't really work.

I'm not sure if debian has something like Centos SCL, which are basically different repositories (which means you can often install different versions of packages alongside each other).

Note, if you do go down the docker route, you can benefit from a ton of pre-created images, of which iperf already exists:

https://hub.docker.com/r/networkstatic/iperf3/
https://hub.docker.com/r/mlabbe/iperf/ (based on alpine, so super lightweight)

The problem is, even though they're differently named, installing one removes the other. Is there any way I can get both of these packages installed concurrently?

On Debian at least:

$ apt-get install iperf iperf3
$ iperf -v
iperf version 2.0.9 (1 June 2016) pthreads
$ iperf3 -v
iperf 3.1.3
Optional features available: CPU affinity setting, IPv6 flow label, TCP congestion algorithm setting, sendfile / zerocopy, socket pacing

And that's how it used to work, however from my OP,

compiled from source as there's a showstopping bug in the released binaries

I can't use the repositories for iperf3 and there's something nobby about the iper3 source (or my naive compilation) which makes iperf3 identify as iperf rather than iperf3.

Also,

What repositories are you getting those from? They're both newer than the ones I'm getting from the default Lubuntu repos (not that that fixes the bug issue).

Could you just send them a shell script to install the .deb packages from the iperf website?

Just tested this on Ubuntu 14.04 and seems to work ok and co-exist happily.

These are the steps from the developer site to install a newer version than is in the repos:

sudo apt-get remove iperf3 libiperf0
wget https://iperf.fr/download/ubuntu/libiperf0_3.1.3-1_amd64.deb
wget https://iperf.fr/download/ubuntu/iperf3_3.1.3-1_amd64.deb
sudo dpkg -i libiperf0_3.1.3-1_amd64.deb iperf3_3.1.3-1_amd64.deb
rm libiperf0_3.1.3-1_amd64.deb iperf3_3.1.3-1_amd64.deb


Then install iperf2 in the same way:

wget https://iperf.fr/download/ubuntu/iperf_2.0.5+dfsg1-2_amd64.deb
sudo dpkg -i iperf_2.0.5+dfsg1-2_amd64.deb
rm iperf_2.0.5+dfsg1-2_amd64.deb


Wrap that all up in a shell script and should be a goodun. You'll need to re-issue it when it gets updated, but better than building from source I reckon.

Reference:
https://iperf.fr/iperf-download.php#more-recent

Use pacman 😉

What version of Lubuntu is it? You should be able to find a PPA which will sort you out with a newer version through apt-get.

EDIT: Or, have you enabled backports?

Could you just send them a shell script to install the .deb packages from the iperf website?

No, because as I said in the OP I need to correct a bug present in the released binaries, which is why I'm having to compile from source.

What version of Lubuntu is it? You should be able to find a PPA which will sort you out with a newer version through apt-get.

EDIT: Or, have you enabled backports?

16.04 LTS. I don't know what a PPA or a backport is, but see my previous reply.

I just built the iperf3 debian package from source and it duly puts it in the right place:

pi@raspberrypi:~/iperf3 $ dpkg-deb --fsys-tarfile iperf3_3.0.7-1_armhf.deb|\
  tar tvf -
drwxr-xr-x root/root         0 2016-11-02 10:04 ./
drwxr-xr-x root/root         0 2016-11-02 10:03 ./usr/
drwxr-xr-x root/root         0 2016-11-02 10:04 ./usr/bin/
-rwxr-xr-x root/root      5568 2016-11-02 10:04 ./usr/bin/iperf3

This is on debian rather than ubutnu. But at least on debian, I think building from source should be fine. Unless there's something else I've missed.

The more I think about this, the more I'm convinced that the issue is that the source I'm using is going "hi, I'm iperf" rather than "hi, I'm iperf3." How I'd go about changing that, I don't have a scooby.

On the github there's a few forks; there's "3.1 STABLE" and "master." Master appeared to be the newest / development version and so that's what I was using (though github is something else that frankly baffles me so who knows), but I'm wondering if there's some sort of weirdness going on with the versioning precisely because it's not a release version of the code. I think what I'm going to do is bin everything off, grab a new copy of 3.1 STABLE and start again using that.

Thanks for the help so far folks.

I just built the iperf3 debian package from source and it duly puts it in the right place:

What happens if you then install iperf from the repo?

[s]Which version of source code did you use?[/s] never mind, I've just read it properly.

Aaaaaand that's nailed it. \o/

# which iperf
/usr/bin/iperf

# which iperf3
/usr/local/bin/iperf3

Though bizarrely it's now telling me that the package can be removed with dpkg -r iperf-3.1 - where does it get that name from (ie, how do I make it just add / remove as iperf3)?

Are you sure you haven't got another iperf3 in /usr/bin? which probably only reports the first one it finds.

There's just iperf in /usr/bin. What difference would it make if there was?

Isn't this the scenario that the designers of SNAP foresaw and just by pure chance Ubnuntu 16.04 includes the capability to run SNAPs

http://snapcraft.io/create/

When you did checkinstall, you should have named your package iperf3

like this
[code]checkinstall --pkgname=iperf3 make install[/code]

then you can have

[code]root@rextest2:/var/www/html/iperf-3.1.3# dpkg -l |grep iperf
ii iperf 2.0.5+dfsg1-2 amd64 Internet Protocol bandwidth measuring tool
ii iperf3 3.1.3-1 amd64 Package created with checkinstall 1.6.2
[/code]

Oooh. Give me a sec.

Bingo! Perfect.

That's brilliant, thank you.

(I'm now wondering whether that would've fixed the initial problem in the first place...)

[quote=Cougar ]Bingo! Perfect.
That's brilliant, thank you.
(I'm now wondering whether that would've fixed the initial problem in the first place...)

Welcome.

I now have ...
[code]root@rextest2:/# which iperf
/usr/bin/iperf
root@rextest2:/# which iperf3
/usr/local/bin/iperf3
[/code]

So I guess it would have solved your problem? The binaries both run and show the right version numbers anyway.

Assumes iperf 2 installed already in 16.04

$sudo snap install lcavassa-iperf

Logout, log back in

$lcavassa-iperf.iperf runs iperf v3.1.3

$iperf runs the original

For completeness,

dpkg -l | grep iperf
ii  iperf                                 2.0.5+dfsg1-2                            amd64        Internet Protocol bandwidth measuring tool
ii  iperf3                                3.1.4.M-1                                amd64        Maintel iperf3 build
ii  libiperf0:amd64                       3.1.3-1                                  amd64        Internet Protocol bandwidth measuring tool (runtime files)

Now installed into my image and working fine. Thanks again.

...out of interest, Cougar....

You mentioned that this is for a field-force of some kind (sounds like remote network testing/proving). You've managed to get them to run Linux of some kind?

Much hassle?

Yeah, it's for our field-based installation engineers. There's a broad spectrum when it comes to ability as you'd expect, and their networking skills and their PC skills have little bearing on each other. So some of them have taken to Linux like a duck to petrol for sure, whereas some have been really enthusiastic and offered great feedback / suggestions as to what else we could do with it.

Thing is, they still use Windows for day-to-day stuff. For the testing they boot off the USB pendrive, open a terminal, then they're on a command-line where they run iperf commands following a guide. They save captures to a FAT32 partition on the pendrive which they can then frob about with back in Windows. So most of them aren't really "using Linux" per sé.

TBH though, the forerunner to this was some nasty Knoppix live CD someone had cobbled together, so for those few who used the old one this solution is like someone's taken away their Ford Ka and given them an Aston Martin.

Interesting. Good fix that; I used to have to deal with our field guys on a daily basis (network installs and latterly testing too) and the capacity of some of them to do way, way more than expected was always heartening- sometimes, jobs that looked like a multi-day fest could be done in 1 as your tech had already done all the prep. Gawd bless 'em!!!

For our field-based guys (this was a few years ago, mind) someone bought in a dedicated testing solution; this was a server in a DC, connected out to various VRF's (this was all MPLS) via vlans (could do layer 3/4 stuff too) and would look at our records system to verify QoS details on circuits. The fieldies would then run the test from their windows machines, and the server would yes/no. It was nice as you could save the results as a web page and send to the customer as proof; billing could then commence.

It was made by IXIA and was a tremendous amount of money. It was fairly painless when we got it up and running, and the inventory lookup was nice (we used CRAMER for this), but I always felt it was overkill, as the field guys were all very competent, and iperf had worked for me in the past.

I miss those days.....

Cool. We're heading that way I think but a lot of this is in its infancy, I've been in this role for about 12 months and before that it was largely left to stagnate (through no fault of my predecessor I should add, he's one of those people who is always in massive demand by dint of him being too brilliant for his own good).

As for the pendrive, considering I knew very little about Linux when I started this little project, I'm pretty pleased with the end result (and I've learned a lot in the process). See the previous thread I linked to in the second post here.

I think it's a pretty elegant solution over a persistent Live [s]CD[/s] USB. The beauty of it is that the source is a VM, so I can easily back it up, spin it up to make system changes, apply updates, add features, then it's just a single flat image file I can burn to USB. I've even got a process now where I can burn it from Windows, which suddenly makes it friendly for Linux-curious engineers who can download it from my OneDrive account and roll their own drives (and moreover, saves me having to re-burn umpteen drives at 20 minutes per stick every time there's a major change).