I originally installed GNU Radio on this computer when it was networked
via
pybombs. Since then, the computer has become air gapped (no internet
connection allowed). I need to update the install to the latest versions
of
UHD and GNU Radio. Two questions:
Is there a way that would allow me to use pybombs to update from a
dvd?
If so, how would I create this dvd and then point pybombs to it?
Should I forget the original pybombs install and start over with a
dvd
containing all files needed to install the latest version. If so, how do
I
make this dvd?
depends. Many of the things that pybombs does actually consist of
calling your distro’s package manager. So if you can do that with a DVD
source, you’re set (I remember this being relatively easy on debian,
with a DVD actually being a remote just like debian’s repo servers are);
for the things you build from source: well, you can always just edit all
recipes involved and change the URLs to something locally served, I
guess
That’s easier. Use “pybombs package”, and you get a tar.gz of your
prefix. again, this will only include things that are not installed by
using your distro’s package manager.
I’ll try the second approach. I created the target.tar.gz from a
computer
(same OS) that is networked and fully updated. I have copied this over
to
the air gapped machine, but now what do I do? Just having the target
folder
isn’t enough to update the install. How do I update from here?
Thanks for helping me through this Marcus, I appreciate it.
Another words, if I installed Doxygen on my non-air gapped computer and
used this to make the target.tar.gz then the air gapped computer must
have
Doxygen installed as well for the install to work?
I’m running into a problem that might be related to this, in that when I
start grc on the air gapped computer after extracting the target.tar.gz
to
it, it prints the welcome to gnu radio 3.7.8 message but then barfs on
the
following error
File …/target/lib/python2.7/dist-packages/gnuradio/grc/base/odict.py",
line 34, in getitem
return self.data[key]
KeyError: ‘options’
Do you know what problem this represents?
For my understanding, please help me understand this:
As far as the prefix directory is concerned, in a normal pybombs install
where the prefix is a local user directory, you are saying that the
prefix
directory is self contained and all that is needed for a working GRC,
assuming all dependencies are installed, is this correct? The build
process
doesn’t throw files into /usr/local directories or share directories or
any
other central locations?
Well, if you installed into a prefix on the air gapped computer, too,
you’d just overwrite everything in there with the contents of the
archive.
You must make absolutely sure that you bring all distro packages that
are related in any way to the software you’ll run to the same version
that you’ve got on your online PC.
To be honest, this sounds like something you should ask the people that
decide that and how you air gap your computer.
I think the only practical way to have both an immediately updateable
and yet air-gapped PC is to keep your data as cleanly archivable and
restorable as possible, and script your set up routines as far as
possible. Whenever you need an update, you then make a backup of your
work, flatten the air-gapped PC, use your scripts to set up the
environment in an up-to-date state, and then air-gap and restore your
work. Everything else is just asking for extra hours.
no solution here, but this is interesting because these kinds of
problems are one of the reasons why we’re re-working PyBOMBS. Are USB
drives allowed? I guess if so, you could fetch-all on one machine,
update a USB drive, and then have PyBOMBS read repos from that.
Of course, air-gapping becomes kind of pointless if you can install
anything from a USB drive.
well, Doxygen is not the best example, because it’s only needed to
generate documentation at build-time.
But consider this: when you set up your soon-to-be-airgapped computer,
you install python 2.7.8-15a-spam including the matching development
headers.
You do the same on your on-line machine.
After a month or so, you decide you might want to update the python
installation on your on-line computer. You do that, it’s now
2.7.9-vikings. Another month passes. You realize that “having the most
recent version of GR on the air-gapped computer” might be desirable. So
you use pybombs to update GNU Radio on your on-line PC.
The problem now is that the version of python on your air-gapped
computer (spam) doesn’t match the one that the fresh GNU Radio was
linked against. Since spam doesn’t have the same symbols as vikings,
things go wrong as soon as you try to call a python function from C++.
That might lead to confusion and ruin [1].
The same mechanism applies to all libraries that GNU Radio or any of the
things you build on your on-line PC. So you’d have to make absolutely
sure that the libraries installed on your on-line PC match the versions
on the air-gapped one.
Yes you’re right that we can’t use USB drives, but I should be able to
do
the same thing on a DVD. Can you explain the steps you would use to
create
the USB drive and I will do that on a DVD instead. This is the part I’m
just not sure how to do.
Alright. I’m understanding there is no good way to keep an air gapped
computers GNU Radio up to date because there is no good way of keeping
the
air gapped computers dependencies up to date.
I had hoped other air gappers would speak up and explain how they
maintain
their systems. Oh well.
Similar issues here. On Fedora, you can use reposync to mirror a
repository
to disc, transfer to DVD, then you can point yum to that when
installing/updating packages on your gapped machine. I believe you can
do
something similar for a git repository, burn to DVD, then point it your
DVD
when cloning and pulling. I have not tried the last part. May not be
able
to use pybombs then, but I have actually never used it; I keep a list of
dependencies GR needs, and just cut/paste to yum:
Lou
Richard B. wrote
Alright. I’m understanding there is no good way to keep an air gapped
computers GNU Radio up to date because there is no good way of keeping the
air gapped computers dependencies up to date.
I had hoped other air gappers would speak up and explain how they maintain
their systems. Oh well.
