Re: Moving Linux Installation OFF Virtual Machine and Into Real World ???

From	"25B.Z969" <25B.Z969@noda.net>
Newsgroups	comp.os.linux.misc
Subject	Re: Moving Linux Installation OFF Virtual Machine and Into Real World ???
Date	2022-08-14 03:08 -0400
Organization	Aioe.org NNTP Server
Message-ID	<tda72b$1c97$1@gioia.aioe.org> (permalink)
References	<eqGdnUmhFNW5Q2j_nZ2dnUU7-T3NnZ2d@earthlink.com> <slrntfbofo.1ks82.BitTwister@wb.home.test> <td7aen$15ui$1@gioia.aioe.org> <slrntfega4.1va1f.BitTwister@wb.home.test>
Show all headers | View raw
On 8/13/22 2:14 AM, Bit Twister wrote:
> On Sat, 13 Aug 2022 00:48:23 -0400, 25B.Z969 wrote:
>> On 8/12/22 1:15 AM, Bit Twister wrote:
>>> On Fri, 12 Aug 2022 00:59:15 -0400, 25B.Z969 wrote:
>>>> I often test OS distros by installing them on VMs - KVM or
>>>> Virtualbox.
>>>>
>>>> Thing is, while playing with them I often make a LOT of useful
>>>> tweaks, load a lot of software, get it working REALLY WELL.
>>>> Half the time I can't remember all the tweaks,
>>>
>>> So write what you do/did in an admin diary.
>>
>>
>>     A what ???  :-)
> 
> Usually an ASCII text file with date/time and description of what
> was changed from/to in a file.


   Not my style  :-)

   I hyper-doc PROGRAMS though.


>>>> the other half
>>>> of the time so MUCH time was spent getting it right I just
>>>> don't want to do it all over again.
>>>
>>> That is what automation is for.
>>> You either let the computer work you or make the computer work for you.
>>>
>>> So what will you do when your "Production" install no longer works
>>> after an upgrade or whatever?
>>
>>
>>     I don't get THAT crazy - but I do keep backups of the
>>     working scripts, config.files and such. However moving
>>     all of that to a new installation is a pain, and I'm
>>     just a bit lazy ... ok, OLD ...
> 
> Yep I know just what you are saying, but old release configuration files
> may not be compatible with new release.

   The updaters usually take care of that pretty well. At the
   very least apt/apt-get will ASK you if you want to replace
   a customized config file.

   Anyway, my immediate focus is on moving the VM into the
   real world. Various ways have been suggested - on checking
   some 'fixes' seem to spend a LOT of time explaining why
   they won't work very well. Discouraging. I just want to
   kinda make a 'dd' image, then move it to an actual drive
   partition. The tricky bit is that you have to make the
   image of a running system from the running system. It
   should mostly work, mostly ...

   The most important two are on KVM, one on VBox.


>>> I used to document every change until it dawned on me to write
>>> scripts to do the changes for me.
>>
>>     Not a bad idea ... but then you've STILL "documented",
>>     inside the scripts.
> 
> Other than the code very little why/what commenting.

   Well, you CAN comment the hell out of it ....

>>
>>> I can now do clean installs run my scripts and have everything as I
>>> want it.
>>
>>     Ought to work fairly well, but for EVERY tweak ?
> 
> Yep,
>    cd /local/bin
>     ls *install* | wc -l
>     61
>     ls *change* | wc -l
>     198
> 
> even my Desktop Environment changes. I use Xfce as my DE and use
> xdotool dump/set my changes. Dead easy to use a junk account,
> dump pristine user settings, Go through each gui user DE configuration screen
> dump settings again and diff got me all the changes to automate.

   I'm gonna try some of these approaches next week. I'll
   report which seem to work the best.

>>     I tend to hammer at these issues until I get a
>>     setup that does what I want ... but I often do
>>     the tweaking so fast, with so many trial variants,
>>     that remembering everything - even to write it in
>>     a script - can be difficult.
> 
> Seems simple enough to me. Save file before change, use diff to
> get what was changed, modify script to taste.

   Um ... maybe ten tweaks, sometimes to one config file, in
   and hour - trial and error until the damned thing WORKS.
   I generally keep an ".old" or two, but .....

   In this respect I'm closer to a 'hack' ... but made 30+
   years of fair money doing it this way. FAST is the
   imperative for my niche.


> It does help to already have skeleton/boilerplate scripts to have 90%
> of the grunt work done.
> 
>    ls *skeleton*
>    bash_skeleton       skeleton_sb_drop_in_changes
>    install_skeleton    skeleton_service_changes

   Always good. Don't always get DONE though  :-)

> I have the Aide package installed on my Mageia 8 Release OS.
> Makes is easy to find new/changed files/links.
>    http://sourceforge.net/projects/aide
> 
>>     There are two kinds of programmers. If the bosses
>>     need it *eventually* there were some other guys,
>>     who'll spend months carefully diagramming it all
>>     out.
> 
> Yeah I find the six P's can help, You know Prior Planning Prevents
> Piss Poor Performance..

   PPPTR ... Prior Planning Prevents TIMELY RELEASE  :-)

>>   If they needed it working by Monday morning then I was the guy.
> 
> Hehehe, being a Maintenance Programmer I have had to fix a lot of that
> methodology.


   Sure ... but the boss HAS IT WORKING when it's WANTED/NEEDED.

   Polish-up LATER. That can be fun too.


>>     Once I get going I can kinda
>>     build and hold the whole equation in my head,
>>     it all evolves almost in a fractal fashion.
> 
> Yep, been there and beats having to create Requirements and Design specs.
> Sounds like it would be easy for you to create all the functions to
> do scut work then dead easy to find the lines to set you changes.

   I just blast it into existence, might completely re-do the
   paradigm a few times in a day as current/future needs pop
   into my head. There's money in the BY MONDAY MORNING
   programming niche. The well-planned super-big apps, well,
   those are for the Other Guys - but ya ain't gonna have it
   by Monday morning ......

   And sometimes those big ultra-planned/perfectly-structured
   apps wind up being SO rigid that you can't squeeze a tweak
   the boss/customer wants in there without collapsing the
   whole house of cards.

   The "best way" is probably in-between somewhere.


>> I'm
>>     now a little old for that, not the same old energy
>>     and hyper-focus. But I had my day and purpose.
> 
> Yeah, and if you are like me, not remembering everything needing to be
> done where. I think you mentioned adding stuff. On mine I have
>        grep rpm install_addons | wc -l
>        151
> extra stuff.
> 
>>     Charlie will confirm - find the small/medium-sized
>>     places and it'll always be INTERESTING - you'll never
>>     "work" another day in your life.
> 
> Yup, mine started out as an engineers aid to wire/debug interface boards
> to test cards. Pretty soon designing, wire it, write the program to test
> new card and debug my interface card, my testing program and once in
> a while the card under test.

   Ah ... somebody else who "programs in Solder" once in a
   while  :-)

   I was annoying everybody by insisting that there are really no
   boundaries between software/firmware/hardware ... all are one
   and one is all ....

   For awhile I was making 'embedded' stuff for people who needed
   to do environmental monitoring - and often changed their minds
   about WHAT they needed to monitor. Often there really weren't
   any off-the-shelf solutions to their particular wants plus the
   environments the things would be used in (like salt water or
   boiling/freezing conditions) So - you build the Whole Thing ...
   code+microcontrollers+sensor-adapter-boards (some with smaller
   microcontrollers of their own). I2C,SPI,1-Wire,RS232/485 - have
   to leverage them all. Then the systems to be used in vehicles -
   pumps, monitors, GPS, electrically-noisy environs ... good
   education in why opto's can be your friend ....

   And they always want it REAL QUICK  :-)

>>     ANYway ... I want the best path for moving common VMs
>>     off into the non-virtual universe. VMs have their place,
>>     but they have more weird issues too. The WORST aspect
>>     of VMs is that cheap places love to put ALL those eggs
>>     in ONE hardware basket - and then you get a hole in
>>     that basket one day ..........
> 
> Yep, I use Virtualbox to test all my scripts for each new OS release.

   I've found that VBox isn't good for *everything*. Often you
   can install something in VBox ... but sometimes it goes
   better in KVM. The various add-on paks that help VBox
   interface with the real world can also be an impediment,
   while the more system-level stuff KVM wants for interfacing
   with local networks is actually more portable. Xen, at
   this point, seems to be falling behind the curve alas
   and VMWare is more and more $$$.

   VMs ARE super-good for checking suspicious e-mails/attachments
   though ... irrelevant if they're corrupted/infested. For that
   kind of stuff I have Kali VMs with all the forensic apps. The
   evil people are getting VERY clever these days ... impossible
   to train all the 'average users' to look for all possible
   scam methods. At best I can dissect scam mails, write a little
   one-page expo on WHY/HOW they were scamming. It does help,
   makes the staff more suspicious, less ready to trust, less
   likely to just click the "Click Me !" button ....

   The latest trend is Fake Invoices. Sometimes they look/feel
   VERY real - might even seem kind-of related to what the cpny
   is doing at the moment (the Evils do keep track, even check
   construction permits being made and make deductions). One
   outfit got a bill, supposedly from a local company, for some
   concrete work - but the bill SHOULD have gone to the primary
   contractor ... and the company was real, but only did a
   completely different kind of concrete work. Another
   construction company, again a REAL name, only did work
   overseas. Mis-spelling tricks, hidden links, fake QuickBooks
   billings, seeming US addresses that, once checking, went to
   eastern europe ...... at best you can make the staff PARANOID
   about anybody wanting money/passwords/acct#'s etc. They do
   not have the skills/time to really check-out this stuff.


> Found it handy to have a change counter and test it for match.
> If not, I have to delve into new configuration file to see what has changed.

   I've done that ... though probably not as often as I should have.
   My niche was "fast and loose". It has it's place. Always wrote
   code so you could jam some weird change/improvement in there
   somewhere without re-writing half the pgm. Kinda left over from
   the old "batch job" days - everything step-by-step - so you
   can easily insert an odd very-different step in there. It's
   neater/smaller if you combine operations, but you lose that
   patching flexibility.

> Regardless how you get the vm machine onto real hardware, you still
> have to make hardware difference changes.

   Well ... Linux does most of it's hardware detection at boot.
   A little different from Win in that respect. This does make
   it easier to port between different hardware environs.

> Still recommending install/change scripts to do the work.

   I agree ... but at this point I'm semi-retired. The New Boyz
   will have to do all this. <Perferred-Gawd> Help Them  :-)

   Sometimes the New Girlz are actually better ...

   They think taking a Python course will make them "systems
   guys" or good IT overlords. Sorry, but experiencing all
   the PAST crap - working with diverse systems/languages -
   no real substitute. My first "real programs" were FORTRAN
   writ for a PDP-11/RSX-11m somebody (I'm sure with sadistic
   intent) wired CARD/PTape-readers to even though the thing
   WOULD support terminals. There's just no substitute for
   "coming up thru the ranks". Maybe all the "old guys" say
   that - but it IS really hard to chart a sane course forward
   when you don't know where you've been.

   From the early 60s, yer VAX/360/etc and its language suites
   were set up to get data (slowly) from remote/international
   sources - biz/banking/science. The New Guys think this
   only happened with the internet, don't know the Foundations,
   don't know why TCP/IP exists, don't know about xmodem and
   error detection/correction. For them It Just Works ...
   until some Russkie actor makes sure it doesn't, or finds
   a way to leverage it against you ......

   In a way I lament not getting into it a decade or so
   earlier - the immediate post-UNIVAC world. Those people
   really knew how to get by with less - and how to CREATE
   what they didn't have.
Back to comp.os.linux.misc | Previous | Next — Previous in thread | Next in thread | Find similar
Thread

csiph-web