Mailing List Archive

GUI-less (non-dbus) virt-manager (to run Tails in Gentoo)
Hi!

This is my installation of the package virt-manager:

# equery l virt-manager
* Searching for virt-manager ...
[IP-] [ ] app-emulation/virt-manager-1.4.0-r2:0
#

# emerge -pv virt-manager

These are the packages that would be merged, in order:

Calculating dependencies ... done!
[ebuild R ] app-emulation/virt-manager-1.4.0-r2::gentoo USE="sasl -debug
-gnome-keyring -gtk -policykit" LINGUAS="-as -bg -bn_IN -bs -ca -cmn -cs -da
-de -en_GB -es -fi -fr -gu -hi -hr -hu -is -it -ja -kn -ko -ml -mr -ms -nb -nl
-or -pa -pl -pt -pt_BR -ro -ru -sk -sr -sr@latin -sv -ta -te -tr -uk -vi
-zh_CN -zh_TW" PYTHON_TARGETS="python2_7" 0 KiB

Total: 1 package (1 reinstall), Size of downloads: 0 KiB
#

Also gunzip the equery_f_virt-manager.txt.gz for the list of files, of which I
present only those that I will, apparently, have to try and use, once my
initial query is cleared:

/usr/bin/virt-clone
/usr/bin/virt-convert
/usr/bin/virt-install
/usr/bin/virt-xml

While at the list of files, pls. notice that there is no executable named
'virt-manager' in my system's virt-manager install:

# grep -E '\/?bin\/virt-manager' equery_f_virt-manager.txt
#

or:

# grep 'virt-manager$' equery_f_virt-manager.txt
#

both return empty.

If I try sticking:
echo "app-emulation/virt-manager gtk" >> /etc/portage/package.use/package.use.file

hopeful to get the GUI, then:

# emerge -pv virt-manager

These are the packages that would be merged, in order:

Calculating dependencies ... done!

!!! All ebuilds that could satisfy "x11-libs/gtk+:3[introspection]" have been masked.
!!! One of the following masked packages is required to complete your request:
- x11-libs/gtk+-3.22.5::gentoo (masked by: package.mask)
/etc/portage/package.mask/package.mask.file:
#media-video/libav
#gnome-base/gconf

- x11-libs/gtk+-3.22.4::gentoo (masked by: package.mask)
- x11-libs/gtk+-3.20.9::gentoo (masked by: package.mask)
- x11-libs/gtk+-3.18.9::gentoo (masked by: package.mask)
- x11-libs/gtk+-3.16.7::gentoo (masked by: package.mask, missing keyword)

(dependency required by "app-emulation/virt-manager-1.4.0-r2::gentoo[gtk]" [ebuild])
(dependency required by "virt-manager" [argument])
For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.

#

And that is a story that I have met many times with many packages, and, in
short, it hasn't ever been possible to solve it because in my
security-oriented no-frills true-unix only system I have "-dbus" among other
useflags:

# grep -B3 -A6 '\-dbus' /etc/portage/make.conf
# These are the USE flags that were used in addition to what is provided by the
# profile used for building.
USE="a52 alsa apache2 audit bash-completion berkdb bzip2 caps cdr crypt \
cscope css -dbus dri dvb dvdr fam ffmpeg fontconfig gdbm \
-geoip gif git -gnome gnutls gpm gstreamer gzip hardened \
imagemagick -introspection jack jpeg jpeg2k -kde lame libcaca -libav \
mad maildir mhash mng mplayer ncurses nls ogg opengl -pam png -policykit \
readline sasl sdl -selinux -systemd sysvipc smp sound sox sqlite sqlite3 \
ssl subversion svg tiff truetype -udev unicode v4l vim-syntax vorbis \
X x264 xattr xine xv xvid zlib -pulseaudio"

(
A sidenote: notice what is banned with the '-' prefix. It's an
non-poetterware [1], true-unix only system, and the 'hardened' useflag is of
course for grsecurity-based hardened system, not for NSA Linux based. Oh
sorry, I meant SELinux, but NSA, at the turn of the millenium, created SELinux
just as, say, Mozilla, back in the Netscape days, created Javascript. So it
should be called that, shouldn't it?
)

So I guess, to get Tails installed, the way I will need to follow:

https://tails.boum.org/doc/advanced_topics/virtualization/virt-manager/index.en.html

is certainly not literally. Exampli gratia, there is not anything to click at
at all in my virt-manager, for me to be able to follow, say, let me paste just the
first step into here from that "advanced_topics" Tails page:

PASTING->
Running Tails from an ISO image

Start virt-manager.
Double-click on localhost (QEMU) to connect to the QEMU system of your host.
To create a new virtual machine, choose File -> New Virtual Machine.
In step 1, choose Local install media (ISO image or CDROM).
In step 2, choose:
Use ISO image, then Browse..., and Browse Local to browse for the ISO image that you want to start from.
OS type: Linux.
Version: Debian Wheezy.
In step 3, allocate at least 1024 MB of RAM.
In step 4, disable storage for this virtual machine.
In step 5:
Type a name for the new virtual machine.
Click Finish to start the virtual machine.
->PASTED

Instead, I fear that I am left to these:

/usr/bin/virt-clone
/usr/bin/virt-convert
/usr/bin/virt-install
/usr/bin/virt-xml

to accomplish the above GUI tasks, but translated into command line tasks, of
course.

Am I correct? And [I]f [I] [U]nderstand [C]orrectly, has anybody done this
yet? And (again, IIUC) surely there must be Gentooers who did this?! But
(again, IIUC and there are Gentooers who accomplished that), can they tell us
what exact commands they used?

And, on my part, if I ever make it before any of the assumed existing
Gentooers who acoomplished the no-GUI virt-manager Tails installing and
running tell us, if I ever make it, I will tell everybody the commands that I
used to accomplish that.

By the way, it's good to get more in depth and in detail about things ;-)
It is only now that I have noticed that there is a dedicated (well, libvirt
and things) ML... Only now! (The http://virt-manager.org$ is listed in bottom
if you run 'eix virt-manager', and visiting it I found the ML.)

So, the mailing list:

https://www.redhat.com/mailman/listinfo/virt-tools-list

(
And it's good to get more in depth when posting questions because you often
get (some) answers from your own self while posting :-) .
)

But still, this part that I post here is mostly Gentoo specific, and then, I am
also curious if I will get not-so-warm reception
(
I just subscribed, and will point
to this in-depth Gentoo-installation details in this email, when I post my
question there.

But I intend just to ask how to get my GUI-less virt-manager to run Tails as
VM, and not go into moral details of dbus-imposition there _at all_.
)

Why "not-so-warm reception"? Because in Gentoo, we often emphasized the
red-hattisms and systemDestruction as detrimental to true-unix way things
should be...

But lo and behold, the relatively small, poor money, if any, involved
(
Gentoo is one of the most scantily financed FOSS entities in the whole of
GNU-FOSS'dom. When there's no GSoC, not even the tiny dimes, the stingy tiny
dimes that the Schmoog the Scmoogle heavy heartedly departs from, nay, tear
away from their hearts wreaking in moneys...

To learn about, pls. consider viewing:
Gentoo Foundation, background and status report Robin Johnson
https://youtu.be/S3bmXVbxMgE

{When there's no [G]oogle [S]ummer [o]f [C]ode}, the financial entries is a
truly tiny tiny trickle, and the Schmoog pays only, basically, and I guess
really stingily for that too, for the code it gets from the participating
Gentoo developers. It's a pay, not a donation. And it uses Gentoo in its
CoreOS that it deploys. And so donates, in essence, nothing for the use of it.
Like a huge parasite on a healthy body, yes!

Don't worry, the stingy spies on the whole world, the Schmoog, won't opt for
anything but Gentoo for their CoreOS, because nothing matches Gentoo... And
you don't get a community like Gentoo created just so easily, so the big one
here really is Gentoo, not the Schmoog, they are kind of just a small user.
here.

Oh, if I were rich, I would donate to Gentoo, I would!
)

[But lo and behold], we depend on the big Red Hat (full of U.S. military's
id est U.S. of America taxpayers' moneys) for virtualization, and, does this
not sound strange?, we depend on the big Red Hat to..., take good notice: to
get anonymous?!

We depend on the big Red Hat...

...to get ...anonymous?!

The Red Hat that is all for poetterware, all for systemd, all for *kits and
pulseaudio and things, which, the majority of us in Gentoo (the hardest of all
Linuces to understand and use, and the most advanced in most respects; nothing
can work as reliably on your system as what you install by compiling
specifically for your system, and especially if you can install it almost
really in any way on Earth that you can think of), [we depend on]... [the Red
Hat that is all for poetterware] that we, mostly, do not want in our boxen.

And we get virtualization, on which anonymization ever more often depends
upon, from that beast of financially nearly unlimited resources (at least in
comparison to Gentoo Foundation), and it is resources from, essentially, one
superpower's of the world only?!

This is beyond me now... It's too big to understand. Maybe just: I prefer to
remain poor. At least nobody will ever be able to claim, as, in secret, they
can for many, that they bought me.

I decided to post this query integral, with big picture included prominent.

But I won't go about it in endless discussions, should any ensue. Surely will
read every sensible arguments proposed, pro or con, if any will be claimed.

But I'm really mostly eager to get Tails running in my Gentoo...

And someone would really need to dismiss big-time my arguments that I wrote in
this email, for me to put yet more of my time into discussion on the more
moral sides of this matter.

I came to Gentoo, ninth year of my using of Gentoo is this current year 2017,
because in Gentoo I found the best. And I understand ever more what Gentoo is,
and want to tell others about it so others get to know Gentoo, be it that they
decide even for the non-true unix options available in Gentoo, or even for the
NSA Linux however much that I could never recommend it...

And this is, to my best understanding, my integral view on the issue about
virt-manager, a program that I need if I want to get Tails running in my
Gentoo system. This is my integral view because it is comprising of the
aspects that are, even though partly technical, still more in the moral and
ethical domain in their nature, and which aspects are yes: very important.

These aspects go beyond the merely technical deployment of the said
virt-manager, but are, yes theya are: very important to understand.

Exampli gratia, why would there be the need to impose dbus if you want to run
a GUI that runs those commands? Why?

Why? Here's why: dbus is embattled. It is being abandoned by a growing
majority of unix-oriented FOSS developers. Just an example or two: in Devuan,
the very young Debian non-systemd fork, developers regard it as mostly a systemd
impositioner. The GnuPG developers didn't want to use it, because they openly
didn't trust it. And I'm certain every informed developer can tell you many
more really good examples.

And so, why not get a nice point of entry for the embattled dbus! they must
have thought!

People like me, which are not as advanced as to, say, convert programs to
their liking, get to a page like (link already given above, repeating it):
https://tails.boum.org/doc/advanced_topics/virtualization/virt-manager/index.en.html
and they see they can't (easily) install virt-manager without installing dbus,
and so, what happens?

Very few of the likes of me (in the level of aptness for developing) have the
kind of time like this time that I am dedicating to this issue, and what do
they do? They install that poetterware-introducer opaque dbus thing! And the
poetterization of their system is almost guarrantied! How dirty...!

----
[1] poetterware stands for Poettering ware, after the name of the main
developer (or if it shows right in your mail client, and in the web: Lennart
Pöttering, written with the German "ö", o with umlaut, in original charset
--it should show, UTF-8 is set in my Mutt--; btw he is not a kind German that
I admire, and I am somewhat of a fan of teutonic culture and teutonic ways of
life), who is the main author of systemd and other non-true unix and non-true
FOSS programs that plague huge swaths of FOSS nowadays.

--
Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr
Re: GUI-less (non-dbus) virt-manager (to run Tails in Gentoo) [ In reply to ]
I made it!

See:
http://www.croatiafidelis.hr/foss/cap/cap-170113_tails/
or open:
$ <your-browser> \
http://www.croatiafidelis.hr/foss/cap/cap-170113_tails/Screen_170113_2102_g0n_1.webm

(and also Screen_170113_2102_g0n_2.webm and Screen_170113_2102_g0n_3.webm )

But there are stories to tell, along with patches to share, and a place
for a nice bug report, coming.

( only when it's short info, and clear from the title what it's about,
do I top post )

On 170111-21:55+0100, Miroslav Rovis wrote:
> Hi!
>
> This is my installation of the package virt-manager:
>
> # equery l virt-manager
> * Searching for virt-manager ...
> [IP-] [ ] app-emulation/virt-manager-1.4.0-r2:0
> #
>
> # emerge -pv virt-manager
>
> These are the packages that would be merged, in order:
>
> Calculating dependencies ... done!
> [ebuild R ] app-emulation/virt-manager-1.4.0-r2::gentoo USE="sasl -debug
> -gnome-keyring -gtk -policykit" LINGUAS="-as -bg -bn_IN -bs -ca -cmn -cs -da
> -de -en_GB -es -fi -fr -gu -hi -hr -hu -is -it -ja -kn -ko -ml -mr -ms -nb -nl
> -or -pa -pl -pt -pt_BR -ro -ru -sk -sr -sr@latin -sv -ta -te -tr -uk -vi
> -zh_CN -zh_TW" PYTHON_TARGETS="python2_7" 0 KiB
>
> Total: 1 package (1 reinstall), Size of downloads: 0 KiB
> #
>
> Also gunzip the equery_f_virt-manager.txt.gz for the list of files, of which I
> present only those that I will, apparently, have to try and use, once my
> initial query is cleared:
>
> /usr/bin/virt-clone
> /usr/bin/virt-convert
> /usr/bin/virt-install
> /usr/bin/virt-xml
>
> While at the list of files, pls. notice that there is no executable named
> 'virt-manager' in my system's virt-manager install:
>
> # grep -E '\/?bin\/virt-manager' equery_f_virt-manager.txt
> #
>
> or:
>
> # grep 'virt-manager$' equery_f_virt-manager.txt
> #
>
> both return empty.
>
> If I try sticking:
> echo "app-emulation/virt-manager gtk" >> /etc/portage/package.use/package.use.file
>
> hopeful to get the GUI, then:
>
> # emerge -pv virt-manager
>
> These are the packages that would be merged, in order:
>
> Calculating dependencies ... done!
>
> !!! All ebuilds that could satisfy "x11-libs/gtk+:3[introspection]" have been masked.
> !!! One of the following masked packages is required to complete your request:
> - x11-libs/gtk+-3.22.5::gentoo (masked by: package.mask)
> /etc/portage/package.mask/package.mask.file:
> #media-video/libav
> #gnome-base/gconf
>
> - x11-libs/gtk+-3.22.4::gentoo (masked by: package.mask)
> - x11-libs/gtk+-3.20.9::gentoo (masked by: package.mask)
> - x11-libs/gtk+-3.18.9::gentoo (masked by: package.mask)
> - x11-libs/gtk+-3.16.7::gentoo (masked by: package.mask, missing keyword)
>
> (dependency required by "app-emulation/virt-manager-1.4.0-r2::gentoo[gtk]" [ebuild])
> (dependency required by "virt-manager" [argument])
> For more information, see the MASKED PACKAGES section in the emerge
> man page or refer to the Gentoo Handbook.
>
> #
>
> And that is a story that I have met many times with many packages, and, in
> short, it hasn't ever been possible to solve it because in my
> security-oriented no-frills true-unix only system I have "-dbus" among other
> useflags:
>
> # grep -B3 -A6 '\-dbus' /etc/portage/make.conf
> # These are the USE flags that were used in addition to what is provided by the
> # profile used for building.
> USE="a52 alsa apache2 audit bash-completion berkdb bzip2 caps cdr crypt \
> cscope css -dbus dri dvb dvdr fam ffmpeg fontconfig gdbm \
> -geoip gif git -gnome gnutls gpm gstreamer gzip hardened \
> imagemagick -introspection jack jpeg jpeg2k -kde lame libcaca -libav \
> mad maildir mhash mng mplayer ncurses nls ogg opengl -pam png -policykit \
> readline sasl sdl -selinux -systemd sysvipc smp sound sox sqlite sqlite3 \
> ssl subversion svg tiff truetype -udev unicode v4l vim-syntax vorbis \
> X x264 xattr xine xv xvid zlib -pulseaudio"
>
> (
> A sidenote: notice what is banned with the '-' prefix. It's an
> non-poetterware [1], true-unix only system, and the 'hardened' useflag is of
> course for grsecurity-based hardened system, not for NSA Linux based. Oh
> sorry, I meant SELinux, but NSA, at the turn of the millenium, created SELinux
> just as, say, Mozilla, back in the Netscape days, created Javascript. So it
> should be called that, shouldn't it?
> )
>
> So I guess, to get Tails installed, the way I will need to follow:
>
> https://tails.boum.org/doc/advanced_topics/virtualization/virt-manager/index.en.html
>
> is certainly not literally. Exampli gratia, there is not anything to click at
> at all in my virt-manager, for me to be able to follow, say, let me paste just the
> first step into here from that "advanced_topics" Tails page:
>
> PASTING->
> Running Tails from an ISO image
>
> Start virt-manager.
> Double-click on localhost (QEMU) to connect to the QEMU system of your host.
> To create a new virtual machine, choose File -> New Virtual Machine.
> In step 1, choose Local install media (ISO image or CDROM).
> In step 2, choose:
> Use ISO image, then Browse..., and Browse Local to browse for the ISO image that you want to start from.
> OS type: Linux.
> Version: Debian Wheezy.
> In step 3, allocate at least 1024 MB of RAM.
> In step 4, disable storage for this virtual machine.
> In step 5:
> Type a name for the new virtual machine.
> Click Finish to start the virtual machine.
> ->PASTED
>
> Instead, I fear that I am left to these:
>
> /usr/bin/virt-clone
> /usr/bin/virt-convert
> /usr/bin/virt-install
> /usr/bin/virt-xml
>
> to accomplish the above GUI tasks, but translated into command line tasks, of
> course.
>
> Am I correct? And [I]f [I] [U]nderstand [C]orrectly, has anybody done this
> yet? And (again, IIUC) surely there must be Gentooers who did this?! But
> (again, IIUC and there are Gentooers who accomplished that), can they tell us
> what exact commands they used?
>
> And, on my part, if I ever make it before any of the assumed existing
> Gentooers who acoomplished the no-GUI virt-manager Tails installing and
> running tell us, if I ever make it, I will tell everybody the commands that I
> used to accomplish that.
>
> By the way, it's good to get more in depth and in detail about things ;-)
> It is only now that I have noticed that there is a dedicated (well, libvirt
> and things) ML... Only now! (The http://virt-manager.org$ is listed in bottom
> if you run 'eix virt-manager', and visiting it I found the ML.)
>
> So, the mailing list:
>
> https://www.redhat.com/mailman/listinfo/virt-tools-list
>
> (
> And it's good to get more in depth when posting questions because you often
> get (some) answers from your own self while posting :-) .
> )
>
> But still, this part that I post here is mostly Gentoo specific, and then, I am
> also curious if I will get not-so-warm reception
> (
> I just subscribed, and will point
> to this in-depth Gentoo-installation details in this email, when I post my
> question there.
>
> But I intend just to ask how to get my GUI-less virt-manager to run Tails as
> VM, and not go into moral details of dbus-imposition there _at all_.
> )
>
> Why "not-so-warm reception"? Because in Gentoo, we often emphasized the
> red-hattisms and systemDestruction as detrimental to true-unix way things
> should be...
>
> But lo and behold, the relatively small, poor money, if any, involved
> (
> Gentoo is one of the most scantily financed FOSS entities in the whole of
> GNU-FOSS'dom. When there's no GSoC, not even the tiny dimes, the stingy tiny
> dimes that the Schmoog the Scmoogle heavy heartedly departs from, nay, tear
> away from their hearts wreaking in moneys...
>
> To learn about, pls. consider viewing:
> Gentoo Foundation, background and status report Robin Johnson
> https://youtu.be/S3bmXVbxMgE
>
> {When there's no [G]oogle [S]ummer [o]f [C]ode}, the financial entries is a
> truly tiny tiny trickle, and the Schmoog pays only, basically, and I guess
> really stingily for that too, for the code it gets from the participating
> Gentoo developers. It's a pay, not a donation. And it uses Gentoo in its
> CoreOS that it deploys. And so donates, in essence, nothing for the use of it.
> Like a huge parasite on a healthy body, yes!
>
> Don't worry, the stingy spies on the whole world, the Schmoog, won't opt for
> anything but Gentoo for their CoreOS, because nothing matches Gentoo... And
> you don't get a community like Gentoo created just so easily, so the big one
> here really is Gentoo, not the Schmoog, they are kind of just a small user.
> here.
>
> Oh, if I were rich, I would donate to Gentoo, I would!
> )
>
> [But lo and behold], we depend on the big Red Hat (full of U.S. military's
> id est U.S. of America taxpayers' moneys) for virtualization, and, does this
> not sound strange?, we depend on the big Red Hat to..., take good notice: to
> get anonymous?!
>
> We depend on the big Red Hat...
>
> ...to get ...anonymous?!
>
> The Red Hat that is all for poetterware, all for systemd, all for *kits and
> pulseaudio and things, which, the majority of us in Gentoo (the hardest of all
> Linuces to understand and use, and the most advanced in most respects; nothing
> can work as reliably on your system as what you install by compiling
> specifically for your system, and especially if you can install it almost
> really in any way on Earth that you can think of), [we depend on]... [the Red
> Hat that is all for poetterware] that we, mostly, do not want in our boxen.
>
> And we get virtualization, on which anonymization ever more often depends
> upon, from that beast of financially nearly unlimited resources (at least in
> comparison to Gentoo Foundation), and it is resources from, essentially, one
> superpower's of the world only?!
>
> This is beyond me now... It's too big to understand. Maybe just: I prefer to
> remain poor. At least nobody will ever be able to claim, as, in secret, they
> can for many, that they bought me.
>
> I decided to post this query integral, with big picture included prominent.
>
> But I won't go about it in endless discussions, should any ensue. Surely will
> read every sensible arguments proposed, pro or con, if any will be claimed.
>
> But I'm really mostly eager to get Tails running in my Gentoo...
>
> And someone would really need to dismiss big-time my arguments that I wrote in
> this email, for me to put yet more of my time into discussion on the more
> moral sides of this matter.
>
> I came to Gentoo, ninth year of my using of Gentoo is this current year 2017,
> because in Gentoo I found the best. And I understand ever more what Gentoo is,
> and want to tell others about it so others get to know Gentoo, be it that they
> decide even for the non-true unix options available in Gentoo, or even for the
> NSA Linux however much that I could never recommend it...
>
> And this is, to my best understanding, my integral view on the issue about
> virt-manager, a program that I need if I want to get Tails running in my
> Gentoo system. This is my integral view because it is comprising of the
> aspects that are, even though partly technical, still more in the moral and
> ethical domain in their nature, and which aspects are yes: very important.
>
> These aspects go beyond the merely technical deployment of the said
> virt-manager, but are, yes theya are: very important to understand.
>
> Exampli gratia, why would there be the need to impose dbus if you want to run
> a GUI that runs those commands? Why?
>
> Why? Here's why: dbus is embattled. It is being abandoned by a growing
> majority of unix-oriented FOSS developers. Just an example or two: in Devuan,
> the very young Debian non-systemd fork, developers regard it as mostly a systemd
> impositioner. The GnuPG developers didn't want to use it, because they openly
> didn't trust it. And I'm certain every informed developer can tell you many
> more really good examples.
>
> And so, why not get a nice point of entry for the embattled dbus! they must
> have thought!
>
> People like me, which are not as advanced as to, say, convert programs to
> their liking, get to a page like (link already given above, repeating it):
> https://tails.boum.org/doc/advanced_topics/virtualization/virt-manager/index.en.html
> and they see they can't (easily) install virt-manager without installing dbus,
> and so, what happens?
>
> Very few of the likes of me (in the level of aptness for developing) have the
> kind of time like this time that I am dedicating to this issue, and what do
> they do? They install that poetterware-introducer opaque dbus thing! And the
> poetterization of their system is almost guarrantied! How dirty...!
>
> ----
> [1] poetterware stands for Poettering ware, after the name of the main
> developer (or if it shows right in your mail client, and in the web: Lennart
> Pöttering, written with the German "ö", o with umlaut, in original charset
> --it should show, UTF-8 is set in my Mutt--; btw he is not a kind German that
> I admire, and I am somewhat of a fan of teutonic culture and teutonic ways of
> life), who is the main author of systemd and other non-true unix and non-true
> FOSS programs that plague huge swaths of FOSS nowadays.
>
> --
> Miroslav Rovis
> Zagreb, Croatia
> http://www.CroatiaFidelis.hr





--
Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr
Re: GUI-less (non-dbus) virt-manager (to run Tails in Gentoo) [ In reply to ]
On 170113-23:50+0100, Miroslav Rovis wrote:
> I made it!
>
> See:
> http://www.croatiafidelis.hr/foss/cap/cap-170113_tails/
> or open:
> $ <your-browser> \
> http://www.croatiafidelis.hr/foss/cap/cap-170113_tails/Screen_170113_2102_g0n_1.webm
>
> (and also Screen_170113_2102_g0n_2.webm and Screen_170113_2102_g0n_3.webm )
>

Just the end result of how it worked, you can see at, not much there, at this time.

> But there are stories to tell, along with patches to share, and a place
> for a nice bug report, coming.
>

Main story, or tip, that I hope might be useful to others, in this
email.
---

This was the successful command that started the domain "tails" (pls. note
that I will be converting any commands in this email to fit withing 72
char lines, but they were without those "\" at end, and were one long line
each; I'll also be wrapping pastes such as from /var/log/messages):

[.So this was the successful command that started the domain "tails"]:

$ virt-install --name tails --disk tails.img --graphics spice --memory 1024 \
--cdrom tails-i386-2.9.1.iso --livecd --debug |& tee \
virt-install_$(date +%y%m%d_%H%M)_g0n

Also note that the |& tee virt-install_$(date +%y%m%d_%H%M)_g0n is not needed,
but allows me to reconstruct the procedure, to find it in the logs, and of course
that redirection (along with the --debug of course) produced the
debugging log named:

virt-install_170113_0701_g0n

(find it gunzip'ed in the attachment)

However, that command didn't start any GUI, since the no-dbus virt-manager has
no GUI whatsoever.

But, as you can see from that log virt-install_170113_0701_g0n:

[Fri, 13 Jan 2017 07:01:37 virt-install 5357] DEBUG (virt-install:732) Domain
state after install: 1

was there made notice of in bottom, and I take it that it means the domain was
created and started.

And it also gave advice as to what can be done about it (on a previous line):

[Fri, 13 Jan 2017 07:01:36 virt-install 5357] WARNING (cli:487) Unable to
connect to graphical console: virt-viewer not installed. Please install the
'virt-viewer' package.

Which I went about installing, which wasn't easy at all, as you can read below.

During all those 14 hours the VM was running, pretty quietly, it didn't leave
much in the logs...

During most of which time thereof I made many unsuccessful attempts at
installing virt-viewer, and eventually I made it to install it, and ran:

$ virt-viewer tails

which shows in the syslog as:

Jan 13 21:02:53 g0n kernel: [270966.343875] grsec: exec of
/usr/bin/virt-viewer (virt-viewer tails ) by /usr/bin/virt-viewer[bash:30436]
uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:19756]
uid/euid:1000/1000 gid/egid:1000/1000

which is what you can see the screencasts of at:

http://www.croatiafidelis.hr/foss/cap/cap-170113_tails/
(the link already given above)

To be honest, it's not at all so easy to track down exactly how I did it. But
there are a few reasons why I want to do it, the most important being, that I
need to replicate the entire procedure, patches and all, because I completed
this installation in my clone machine, which I also use for test-installs
like this, but the more permanent install I want to do in Air-Gapped [1]
machine, which never goes online, and which installation I can then clone [2]
onto this contacting-with-the-dangerous-and-dirty-internet machine (and other
machines of mine sometimes).

Air-Gapping is complex of course, yes, but it so clean and peaceful.
Especially the updating the Air-Gapped from my local Gentoo mirror with the
portage snapshots signed by the Releng Team. My Air-Gapped is pretty reliably
non-compromised, or at least has been, and continues to be, very difficult to
compromise. And there'll be some strange things to show from this clone,
introduced wih this installation, which don't let me calm and peaceful, there
will be!

Another reason which looke very important to me when I was getting confused if
no-dbus gtk2 virt-manager, along with virt-viewer, was at all possible, is, I
even thought for those hard long hours that it looked impossible, that already
the time was running out to fix
it for everybody, from older packages that would work...

Because there really ended up being no way that I could do it, pls. look it
up:

https://packages.gentoo.org/packages/app-emulation/virt-viewer

with, say, what is currently in testing:

https://gitweb.gentoo.org/repo/gentoo.git/tree/app-emulation/virt-viewer/virt-viewer-5.0.ebuild

While I tried patching quite a few files in the virt-viewer-5.0 source, it
could never anymore be done without making gtk+-2.0 into more of a gtk+-3.0
just without the dbus dependency, which I am not apt to accomplishing.

Instead, I had to bump into my local portage repo this one:

https://gitweb.gentoo.org/repo/gentoo.git/tree/app-emulation/virt-viewer/virt-viewer-3.1.ebuild

(of course for both of those --and other packages that I needed to patch--, I
used the local /usr/portage/app-emulation/virt-viewer to get those ebuilds)

and I was only then able to get that 3.1, patched to 3.1-r1 in my local
overlay, working, and only after bumping spice-gtk-0.31 to local overlay, and
recompiling spice-gtk.

Along with the correct changes in /etc/packages{.use/,.mask/} or whatever
anybody has.

For package.use, add:
=net-misc/spice-gtk-0.31-r1 gtk2
app-emulation/virt-viewer -vnc

For package.mask, add:
>net-misc/spice-gtk-0.31-r1
>app-emulation/virt-viewer-3.1-r1

Pls. find the two ebuilds gzip'ed in the attachment:

spice-gtk-0.31-r1.ebuild.gz
virt-viewer-3.1-r1.ebuild.gz

Since this is a user list, here's how the parts relavant to this
discussion, in my local overlay
(
https://wiki.gentoo.org/wiki/Overlay/Local_overlay
)
look like:

# ls -lR /usr/local/portage/net-misc/
/usr/local/portage/net-misc/:
total 4
drwxr-xr-x 3 root root 4096 2017-01-13 10:02 spice-gtk

/usr/local/portage/net-misc/spice-gtk:
total 20
drwxr-xr-x 2 portage portage 4096 2016-08-25 17:32 files
-rw-r--r-- 1 root root 2277 2017-01-13 10:02 Manifest
-rw-r--r-- 1 portage portage 1052 2017-01-13 09:20 metadata.xml
-rw-r--r-- 1 portage portage 4618 2017-01-13 10:02 spice-gtk-0.31-r1.ebuild

/usr/local/portage/net-misc/spice-gtk/files:
total 12
-rw-r--r-- 1 portage portage 527 2016-08-17 08:36 README.gentoo
-rw-r--r-- 1 portage portage 1141 2016-08-17 22:13 spice-gtk-0.31-x11-libs.patch
-rw-r--r-- 1 portage portage 881 2016-08-17 22:13 spice-gtk-0.32-x11-libs.patch
# ls -lR /usr/local/portage/app-emulation/
/usr/local/portage/app-emulation/:
total 4
drwxr-xr-x 2 root root 4096 2017-01-13 20:19 virt-viewer

/usr/local/portage/app-emulation/virt-viewer:
total 16
-rw-r--r-- 1 root root 1902 2017-01-13 20:19 Manifest
-rw-r--r-- 1 portage portage 452 2016-01-25 00:06 metadata.xml
-rw-r--r-- 1 portage portage 1047 2017-01-13 20:19 virt-viewer-3.1-r1.ebuild
-rw-r--r-- 1 portage portage 922 2017-01-13 09:22 virt-viewer-5.0-r1.ebuild
#

The files that I didn't mention further above, are simply copied over from

/usr/portage/net-misc/spice-gtk
and
/usr/portage/app-emulation/virt-viewer

respectively (without the /local/).

The (gzip'ed) virt-viewer-5.0-r1.ebuild is included for completeness, and to
demonstrate the issue awaiting Gentoo, and any other distro with a
non-poetterware offer, in the future.

I patched it by placing the patch:

gtk+-2_revert.patch

like this:

# ls -lRa /etc/portage/patches/app-emulation/
/etc/portage/patches/app-emulation/:
total 12
drwxr-xr-x 3 portage portage 4096 2017-01-13 10:24 .
drwxr-xr-x 7 portage portage 4096 2017-01-13 10:24 ..
drwxr-xr-x 2 portage portage 4096 2017-01-14 09:21 virt-viewer

/etc/portage/patches/app-emulation/virt-viewer:
total 20
drwxr-xr-x 2 portage portage 4096 2017-01-14 09:21 .
drwxr-xr-x 3 portage portage 4096 2017-01-13 10:24 ..
-rw-r--r-- 1 portage portage 12189 2017-01-13 17:33 gtk+-2_revert.patch
#

(as you can see also I ran chown portage:portage on the whole of
/etc/portage/patches/ dir)

That patch finally got all these properly substituted:

:%s/gtk+-3.0/gtk+-2.0/gc
:%s/3\.10/2\.24\.31/gc
:%s/0\.12\.7/0\.12\.12/gc
:%s/0\.33/0\.31/gc
:%s/3_10/2_24_31/gc
:%s/spice-client-gtk-3.0/spice-client-gtk-2.0/gc

(those are commands with my Vim on the four files that this patch patches,
pls. see the patch),

but it was still to no avail, because they are starting to implement the new
API of GTK3, and the GTK2, which in Gentoo and in some other distros is kept
so dbus is not a dependency, don't have those new calls, functions et cetera.

If anybody is interested, I attach the install log:

app-emulation_virt-viewer-5.0-r1_20170113-164725.log.gz
(that's from /var/log/portage, just I replaced the : with _)

where it's easy to spot lines like:

virt-viewer-app.h:47:5: error: unknown type name 'GtkApplicationClass'

because the new API is missing in GTK2. And the package virt-viewer cannot
possibly compile.

I will next check this in my Air-Gapped, and post errata if any in the next
email to this, in slow time.

I hope my experience is useful to other users with dbus-free Gentoo machines
who want to be able to run Tails via virt-manager in their machines.

Regards!
---
[1] Air-Gapped Gentoo Install, Tentative
https://forums.gentoo.org/viewtopic-t-987268.html
[2] Postfix smtp/TLS, Bkp/Cloning Mthd, Censorship/Intrusion
https://forums.gentoo.org/viewtopic-t-999436.html#7613044

--
Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr
Re: GUI-less (non-dbus) virt-manager (to run Tails in Gentoo) [ In reply to ]
One attachment missing...

On 170114-13:06+0100, Miroslav Rovis wrote:
> On 170113-23:50+0100, Miroslav Rovis wrote:
> > I made it!
...
> /etc/portage/patches/app-emulation/virt-viewer:
> total 20
> drwxr-xr-x 2 portage portage 4096 2017-01-14 09:21 .
> drwxr-xr-x 3 portage portage 4096 2017-01-13 10:24 ..
> -rw-r--r-- 1 portage portage 12189 2017-01-13 17:33 gtk+-2_revert.patch
> #

As you can see, I posted the patch, albeit pertaining to the
unsuccessful install, posted just as demo of more troubles ahead with
the opaque dbus thing in GTK3...

But I forgot to post the ebuild with which the patch does the utmost
possible with the GTK2 setup:

virt-viewer-5.0-r1.ebuild.gz

Just for completeness, as I said.

...

> I will next check this in my Air-Gapped, and post errata if any in the next
> email to this, in slow time.

Still more might be pending. If not, the confirmation when I install it
in Air-Gapped.


--
Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr
Re: GUI-less (non-dbus) virt-manager (to run Tails in Gentoo) [ In reply to ]
More errata.

On 170114-13:06+0100, Miroslav Rovis wrote:
> On 170113-23:50+0100, Miroslav Rovis wrote:
...
>
> The (gzip'ed) virt-viewer-5.0-r1.ebuild is included for completeness, and to
> demonstrate the issue awaiting Gentoo, and any other distro with a
> non-poetterware offer, in the future.
>
> I patched it by placing the patch:

( in the slightly wrong way, because it would try to patch that 3.1-r1
version, not just the 5.0-r1 version )

> gtk+-2_revert.patch
>
> like this:
>
> # ls -lRa /etc/portage/patches/app-emulation/
> /etc/portage/patches/app-emulation/:
> total 12
> drwxr-xr-x 3 portage portage 4096 2017-01-13 10:24 .
> drwxr-xr-x 7 portage portage 4096 2017-01-13 10:24 ..
> drwxr-xr-x 2 portage portage 4096 2017-01-14 09:21 virt-viewer
>
> /etc/portage/patches/app-emulation/virt-viewer:
> total 20
> drwxr-xr-x 2 portage portage 4096 2017-01-14 09:21 .
> drwxr-xr-x 3 portage portage 4096 2017-01-13 10:24 ..
> -rw-r--r-- 1 portage portage 12189 2017-01-13 17:33 gtk+-2_revert.patch
> #

The right way is (with the same patch):

# ls -lRa /etc/portage/patches/app-emulation/
/etc/portage/patches/app-emulation/:
total 12
drwxr-xr-x 3 portage portage 4096 2017-01-13 10:24 .
drwxr-xr-x 7 portage portage 4096 2017-01-13 10:24 ..
drwxr-xr-x 2 portage portage 4096 2017-01-14 09:21 virt-viewer

/etc/portage/patches/app-emulation/virt-viewer-5.0:
total 20
drwxr-xr-x 2 portage portage 4096 2017-01-14 09:21 .
drwxr-xr-x 3 portage portage 4096 2017-01-13 10:24 ..
-rw-r--r-- 1 portage portage 12189 2017-01-13 17:33 gtk+-2_revert.patch
#

where notice the change in this line:

/etc/portage/patches/app-emulation/virt-viewer-5.0:
^ ^ ^ ^ ^ ^ ^ ^

and that does not try to patch 3.1-r1
...

And with regard to this:
> but it was still to no avail, because they are starting to implement the new
> API of GTK3, and the GTK2, which in Gentoo and in some other distros is kept
> so dbus is not a dependency, don't have those new calls, functions et cetera.
>
> If anybody is interested, I attach the install log:
>
> app-emulation_virt-viewer-5.0-r1_20170113-164725.log.gz
> (that's from /var/log/portage, just I replaced the : with _)
>
> where it's easy to spot lines like:
>
> virt-viewer-app.h:47:5: error: unknown type name 'GtkApplicationClass'
>
> because the new API is missing in GTK2. And the package virt-viewer cannot
> possibly compile.
>
you can read in the changelog of the source of virt-viewer-5.0, if you
unpack the virt-viewer-5.0.tar.gz, these lines:

/usr/portage/distfiles/virt-viewer-5.0.tar.gz

virt-viewer-5.0/ChangeLog :

[...]

2016-02-15 Fabiano Fidêncio <fidencio@redhat.com>

Drop support to gtk2
The 3.0 release was the last one that still supports GTK2. For the
Windows builds the support to GTK2 was dropped in the previous release.
Let's do the same for the entire project now.

2016-02-15 Pavel Grunt <pgrunt@redhat.com>

display: Use correct variable name
Fix gtk2 build

[...]

All that means more work for our developers, since I don't believe that
the dbus useflag would be invalidated to impose dbus on Gentoo users,
and if anybody knows that GTK3 might ever in the future drop dependency
to dbus, pls. do tell us!

Otherwise, I was able to follow my tip "GUI-less (non-dbus) virt-manager
(to run Tails in Gentoo)" and the attachments thereof to install all
correctly in my Air-Gapped.

But I want to try and install Tails into, and later run it form, either
real or virtual USB storage, and of course, with persistent volume
available, which will all take me more familiarizing with all these
virtualization tools and ways.

The problem is, and it's my grsecurity hardened kernel that's logging it
in my syslog, the installed virtual machine tails domain keeps trying to
connect to, I guess tor nodes, by inexistent, or fake should I say,
subjects, have a look (it's verbose, but it's complete information about
this segment, along with the information that it is what has been
happening consistently for all these hours since the installation, of
course, the IP addresses of the presumed nodes varying all the time as
well):

Jan 14 21:30:01 g0n kernel: [358997.592199] grsec: (root:U:/) exec of
/usr/bin/find (find /var/spool/cron/lastrun -name cron.daily -cmin +1445
-exec rm {} ; ) by /usr/bin/find[run-crons:22618] uid/euid:0/0
gid/egid:0/0, parent /usr/sbin/run-crons[run-crons:22614] uid/euid:0/0
gid/egid:0/0

[721 lines cut]

Jan 14 21:30:44 g0n kernel: [359041.239800] grsec: (miro:U:/) denied
connect() to 81.7.16.59 port 443 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:31:49 g0n kernel: [359106.109822] grsec: (miro:U:/) denied
connect() to 81.7.16.59 port 443 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:31:49 g0n kernel: [359106.116131] grsec: (miro:U:/) denied
connect() to 87.50.53.32 port 9001 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:31:50 g0n kernel: [359107.107501] grsec: (miro:U:/) denied
connect() to 81.7.16.59 port 443 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:31:50 g0n kernel: [359107.115523] grsec: (miro:U:/) denied
connect() to 87.50.53.32 port 9001 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:31:52 g0n kernel: [359109.111597] grsec: more alerts, logging
disabled for 10 seconds
Jan 14 21:32:04 g0n kernel: [359121.143517] grsec: (miro:U:/) denied
connect() to 81.7.16.59 port 443 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:32:04 g0n kernel: [359121.143729] grsec: (miro:U:/) denied
connect() to 87.50.53.32 port 9001 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:32:20 g0n kernel: [359137.175675] grsec: (miro:U:/) denied
connect() to 81.7.16.59 port 443 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:32:20 g0n kernel: [359137.176224] grsec: (miro:U:/) denied
connect() to 87.50.53.32 port 9001 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:32:52 g0n kernel: [359169.239772] grsec: (miro:U:/) denied
connect() to 81.7.16.59 port 443 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:32:52 g0n kernel: [359169.240334] grsec: (miro:U:/) denied
connect() to 87.50.53.32 port 9001 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:33:57 g0n kernel: [359234.113590] grsec: (miro:U:/) denied
connect() to 81.7.11.154 port 80 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:33:58 g0n kernel: [359235.111410] grsec: (miro:U:/) denied
connect() to 81.7.11.154 port 80 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:34:00 g0n kernel: [359237.115646] grsec: (miro:U:/) denied
connect() to 81.7.11.154 port 80 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:34:04 g0n kernel: [359241.127711] grsec: (miro:U:/) denied
connect() to 81.7.11.154 port 80 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:34:12 g0n kernel: [359249.143691] grsec: (miro:U:/) denied
connect() to 81.7.11.154 port 80 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:34:28 g0n kernel: [359265.175692] grsec: (miro:U:/) denied
connect() to 81.7.11.154 port 80 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:35:00 g0n kernel: [359297.239737] grsec: (miro:U:/) denied
connect() to 81.7.11.154 port 80 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:36:05 g0n kernel: [359362.115614] grsec: (miro:U:/) denied
connect() to 82.168.14.146 port 443 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:36:06 g0n kernel: [359363.115468] grsec: (miro:U:/) denied
connect() to 82.168.14.146 port 443 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:36:08 g0n kernel: [359365.119719] grsec: (miro:U:/) denied
connect() to 82.168.14.146 port 443 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:36:12 g0n kernel: [359369.127756] grsec: (miro:U:/) denied
connect() to 82.168.14.146 port 443 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:36:20 g0n kernel: [359377.143512] grsec: (miro:U:/) denied
connect() to 82.168.14.146 port 443 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:36:36 g0n kernel: [359393.175768] grsec: (miro:U:/) denied
connect() to 82.168.14.146 port 443 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:37:08 g0n kernel: [359425.239710] grsec: (miro:U:/) denied
connect() to 82.168.14.146 port 443 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:38:13 g0n kernel: [359490.109863] grsec: (miro:U:/) denied
connect() to 82.168.14.146 port 443 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:38:13 g0n kernel: [359490.116482] grsec: (miro:U:/) denied
connect() to 176.104.106.208 port 443 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:38:13 g0n kernel: [359490.120103] grsec: (miro:U:/) denied
connect() to 138.201.143.186 port 443 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:38:14 g0n kernel: [359491.107470] grsec: (miro:U:/) denied
connect() to 82.168.14.146 port 443 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:38:14 g0n kernel: [359491.115411] grsec: more alerts, logging
disabled for 10 seconds
Jan 14 21:38:28 g0n kernel: [359505.143856] grsec: (miro:U:/) denied
connect() to 82.168.14.146 port 443 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:38:28 g0n kernel: [359505.144367] grsec: (miro:U:/) denied
connect() to 176.104.106.208 port 443 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:38:28 g0n kernel: [359505.144683] grsec: (miro:U:/) denied
connect() to 138.201.143.186 port 443 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:38:44 g0n kernel: [359521.175737] grsec: (miro:U:/) denied
connect() to 82.168.14.146 port 443 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:38:44 g0n kernel: [359521.176210] grsec: (miro:U:/) denied
connect() to 176.104.106.208 port 443 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:38:44 g0n kernel: [359521.176561] grsec: (miro:U:/) denied
connect() to 138.201.143.186 port 443 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:39:16 g0n kernel: [359553.239487] grsec: (miro:U:/) denied
connect() to 82.168.14.146 port 443 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:39:16 g0n kernel: [359553.239684] grsec: (miro:U:/) denied
connect() to 176.104.106.208 port 443 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:39:16 g0n kernel: [359553.239770] grsec: (miro:U:/) denied
connect() to 138.201.143.186 port 443 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:40:01 g0n kernel: [359597.629894] grsec:
(root:U:/usr/sbin/crond) chdir to /root by /usr/sbin/crond[crond:22668]
uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/crond[crond:3636]
uid/euid:0/0 gid/egid:0/0

[124 lines cut]

Jan 14 21:40:21 g0n kernel: [359618.120247] grsec: (miro:U:/) denied
connect() to 213.246.56.79 port 9001 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:40:22 g0n kernel: [359619.119647] grsec: (miro:U:/) denied
connect() to 213.246.56.79 port 9001 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:40:24 g0n kernel: [359621.123691] grsec: (miro:U:/) denied
connect() to 213.246.56.79 port 9001 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:40:28 g0n kernel: [359625.127686] grsec: (miro:U:/) denied
connect() to 213.246.56.79 port 9001 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:40:36 g0n kernel: [359633.143747] grsec: (miro:U:/) denied
connect() to 213.246.56.79 port 9001 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:40:52 g0n kernel: [359649.175736] grsec: (miro:U:/) denied
connect() to 213.246.56.79 port 9001 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:41:24 g0n kernel: [359681.239728] grsec: (miro:U:/) denied
connect() to 213.246.56.79 port 9001 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:42:29 g0n kernel: [359746.102911] grsec: (miro:U:/) denied
connect() to 213.246.56.79 port 9001 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:42:29 g0n kernel: [359746.110479] grsec: (miro:U:/) denied
connect() to 193.200.241.195 port 9001 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:42:30 g0n kernel: [359747.099633] grsec: (miro:U:/) denied
connect() to 213.246.56.79 port 9001 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:42:30 g0n kernel: [359747.107504] grsec: (miro:U:/) denied
connect() to 193.200.241.195 port 9001 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:42:32 g0n kernel: [359749.103562] grsec: more alerts, logging
disabled for 10 seconds
Jan 14 21:42:44 g0n kernel: [359761.127733] grsec: (miro:U:/) denied
connect() to 213.246.56.79 port 9001 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:42:44 g0n kernel: [359761.143736] grsec: (miro:U:/) denied
connect() to 193.200.241.195 port 9001 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:43:00 g0n kernel: [359777.175676] grsec: (miro:U:/) denied
connect() to 213.246.56.79 port 9001 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:43:00 g0n kernel: [359777.176210] grsec: (miro:U:/) denied
connect() to 193.200.241.195 port 9001 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:43:32 g0n kernel: [359809.239509] grsec: (miro:U:/) denied
connect() to 213.246.56.79 port 9001 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:43:32 g0n kernel: [359809.239698] grsec: (miro:U:/) denied
connect() to 193.200.241.195 port 9001 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:44:37 g0n kernel: [359874.113657] grsec: (miro:U:/) denied
connect() to 88.86.102.163 port 443 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:44:38 g0n kernel: [359875.111493] grsec: (miro:U:/) denied
connect() to 88.86.102.163 port 443 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:44:40 g0n kernel: [359877.115579] grsec: (miro:U:/) denied
connect() to 88.86.102.163 port 443 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:44:44 g0n kernel: [359881.127699] grsec: (miro:U:/) denied
connect() to 88.86.102.163 port 443 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:44:52 g0n kernel: [359889.143540] grsec: (miro:U:/) denied
connect() to 88.86.102.163 port 443 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:45:08 g0n kernel: [359905.175566] grsec: (miro:U:/) denied
connect() to 88.86.102.163 port 443 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:45:40 g0n kernel: [359937.239498] grsec: (miro:U:/) denied
connect() to 88.86.102.163 port 443 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:46:45 g0n kernel: [360002.113731] grsec: (miro:U:/) denied
connect() to 163.172.201.62 port 443 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:46:46 g0n kernel: [360003.111509] grsec: (miro:U:/) denied
connect() to 163.172.201.62 port 443 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:46:48 g0n kernel: [360005.115694] grsec: (miro:U:/) denied
connect() to 163.172.201.62 port 443 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:46:52 g0n kernel: [360009.127499] grsec: (miro:U:/) denied
connect() to 163.172.201.62 port 443 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:47:00 g0n kernel: [360017.143767] grsec: (miro:U:/) denied
connect() to 163.172.201.62 port 443 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:47:16 g0n kernel: [360033.175541] grsec: (miro:U:/) denied
connect() to 163.172.201.62 port 443 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:47:47 g0n kernel: [360064.111102] grsec: (miro:U:/) denied
connect() to 46.19.93.212 port 443 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:47:48 g0n kernel: [360065.111713] grsec: (miro:U:/) denied
connect() to 46.19.93.212 port 443 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:47:48 g0n kernel: [360065.239483] grsec: (miro:U:/) denied
connect() to 163.172.201.62 port 443 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:47:50 g0n kernel: [360067.115705] grsec: (miro:U:/) denied
connect() to 46.19.93.212 port 443 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:47:54 g0n kernel: [360071.127453] grsec: more alerts, logging
disabled for 10 seconds
Jan 14 21:48:18 g0n kernel: [360095.191532] grsec: (miro:U:/) denied
connect() to 46.19.93.212 port 443 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:48:50 g0n kernel: [360127.255502] grsec: (miro:U:/) denied
connect() to 46.19.93.212 port 443 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:48:53 g0n kernel: [360130.105320] grsec: (miro:U:/) denied
connect() to 163.172.201.62 port 443 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:48:54 g0n kernel: [360131.103456] grsec: (miro:U:/) denied
connect() to 163.172.201.62 port 443 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:48:56 g0n kernel: [360133.107721] grsec: (miro:U:/) denied
connect() to 163.172.201.62 port 443 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:49:00 g0n kernel: [360137.111689] grsec: more alerts, logging
disabled for 10 seconds
Jan 14 21:49:24 g0n kernel: [360161.175498] grsec: (miro:U:/) denied
connect() to 163.172.201.62 port 443 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:49:55 g0n kernel: [360192.112941] grsec: (miro:U:/) denied
connect() to 94.23.144.49 port 9001 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:49:56 g0n kernel: [360193.111515] grsec: (miro:U:/) denied
connect() to 94.23.144.49 port 9001 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:49:56 g0n kernel: [360193.239778] grsec: (miro:U:/) denied
connect() to 163.172.201.62 port 443 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:49:58 g0n kernel: [360195.115783] grsec: (miro:U:/) denied
connect() to 94.23.144.49 port 9001 sock type stream protocol tcp by
/var/tmp/portage/app-emulation/qemu-2.8.0/image/usr/bin/qemu-system-x86_64[CPU
0/KVM:5447] uid/euid:1000/1000 gid/egid:1000/1000, parent
/sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 14 21:50:01 g0n kernel: [360197.679030] grsec:
(root:U:/usr/sbin/crond) chdir to /root by /usr/sbin/crond[crond:22717]
uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/crond[crond:3636]
uid/euid:0/0 gid/egid:0/0

[76 lines cut]

Jan 14 21:50:02 g0n kernel: [360199.127671] grsec: more alerts, logging
disabled for 10 seconds

This line shows how verbose the exec_logging is. exec_logging is a
feature of grsecurity. verbose it is because just the every 10 minutes
each hour routine run of the crond takes, as you can see above 78 lines
(of which I cut 76 out).

However, pls. notice that what I have left in that app-emulation
directory of /var/tmp/portage is as follows:

# ls -l /var/tmp/portage/app-emulation/
total 4
drwxr-xr-x 7 portage portage 4096 2017-01-13 17:48 virt-viewer-5.0-r1
# ls -l /var/tmp/portage/app-emulation/virt-viewer-5.0-r1/
total 20
drwxr-xr-x 2 portage portage 4096 2017-01-13 17:47 build-info
drwxr-xr-x 2 root portage 4096 2017-01-13 17:47 distdir
drwxr-xr-x 5 portage portage 4096 2017-01-13 17:47 homedir
drwxr-xr-x 4 portage portage 4096 2017-01-13 17:48 temp
#

and that the 82 times repeated in the logs:

/var/tmp/portage/app-emulation/qemu-2.8.0/

does not exist. So it's a bug, isn't it?

Just to add, nothing whatsoever shows in the network trace, taken by
tcpdump, there is nothing in the network, tcp or ip layer whatsoever of
any of those in the logs, probably because grsecurity blocks them,
although I was offline all this time, none of the nodes could have been
reachable (but while I was installing glibc, the tcpdump recorded
attempts to download glibc-2.23-patches-7.tar.bz2 from the local mirror
which also wasn't set up at the time!).

And I think I first need to ask about it on the https://forums.grsecurity.net .

Pls. notice that the /sys filesystem is often played with by
virtulization people with "very little oversight with an eye toward
security":
https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Sysfs.2Fdebugfs_restriction
, and that they seem to require now the complete freedom in the /sys
pseudo filesystem, as the apparent resolution of the bug:
=sys-kernel/hardened-sources-4.7.6: Kernel panic when starting KVM guests
https://bugs.gentoo.org/show_bug.cgi?id=597554#c72
shows to be the case.

Also, I don't want to go online without grsecurity GRADM protection, and
I had to disable it, else I couldn't start the tails domain VM :-(
yesterday.

And that means more work/study. GRADM policies are far from always easy
to deploy! Not for a non-expert like me...

--
Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr
Re: GUI-less (non-dbus) virt-manager (to run Tails in Gentoo) [ In reply to ]
Not about Tails, this message, but yes it is about GUI-less (non-dbus)
virt-manager.

About its use for installing and running a Tails' relative: Whonix.

I made a well-accepted, I believe, push for Whonix to be installable and
runnable (actually it maybe already is!) in sans-dbus systems.

Pls. if anybody feels passionate enough about Unix heredity staying
sound and prosperous, and you feel you can contribute by helping in this
thread:

Whonix on Gentoo issues
https://forums.whonix.org/t/whonix-on-gentoo-issues/3188

then pls. do contribute!

There is a poor-eyesight old man that I am useless digression somewhere
in one of the first three posts (which I can't remove anymore, old posts
are not editable in Whonix forums), and also previous to below all
attempts of mine were unsuccessful, so...

So maybe if you start from:

https://forums.whonix.org/t/whonix-on-gentoo-issues/3188/7

[from] post 7, you will be sufficiently in the clear what the issue is.

And on a sidenote on this thread that you're reading. I probably need to
re-evaluate the current status of no-dbus virt-manager using virt-viewer
as GUI, with the last night update of Gentoo installtion of mine (always
such a pleasure).

Pls. contribute if you are familiar with Whonix and the issues there!

I've top posted this, because it regards the entire thread, not this
particular email below.

On 170114-22:53+0100, Miroslav Rovis wrote:
> More errata.
>
> On 170114-13:06+0100, Miroslav Rovis wrote:
...
> > If anybody is interested, I attach the install log:
> >
> > app-emulation_virt-viewer-5.0-r1_20170113-164725.log.gz
> > (that's from /var/log/portage, just I replaced the : with _)
> >
> > where it's easy to spot lines like:
> >
> > virt-viewer-app.h:47:5: error: unknown type name 'GtkApplicationClass'
> >
> > because the new API is missing in GTK2. And the package virt-viewer cannot
> > possibly compile.
> >
> you can read in the changelog of the source of virt-viewer-5.0, if you
> unpack the virt-viewer-5.0.tar.gz, these lines:
>
> /usr/portage/distfiles/virt-viewer-5.0.tar.gz
>
> virt-viewer-5.0/ChangeLog :
>
> [...]
>
> 2016-02-15 Fabiano Fidêncio <fidencio@redhat.com>
>
> Drop support to gtk2
> The 3.0 release was the last one that still supports GTK2. For the
> Windows builds the support to GTK2 was dropped in the previous release.
> Let's do the same for the entire project now.
>
> 2016-02-15 Pavel Grunt <pgrunt@redhat.com>
>
> display: Use correct variable name
> Fix gtk2 build
>
> [...]
>
...

Regards!

--
Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr
Re: GUI-less (non-dbus) virt-manager (to run Tails in Gentoo) [ In reply to ]
This email will be about some good results that I have obtained in this
non-dbus virt-manager matter, and at least one snag left to solve...

I have made a lot of progress in using non-dbus virt-manager recently.

I hope some readers might be interested in these not very usual, except
in Gentoo, feats.

Let me remind you:

On 170114-12:48+0100, Miroslav Rovis wrote:
> Hi!
>
> This is my installation of the package virt-manager:
>
> # equery l virt-manager
> * Searching for virt-manager ...
> [IP-] [ ] app-emulation/virt-manager-1.4.0-r2:0
> #
The above is still the case. And so is the below.

> # emerge -pv virt-manager
>
...
>
> /usr/bin/virt-clone
> /usr/bin/virt-convert
> /usr/bin/virt-install
> /usr/bin/virt-xml
>
> While at the list of files, pls. notice that there is no executable named
> 'virt-manager' in my system's virt-manager install:
...

This is what I thought that I needed to do at the onset:
>
> So I guess, to get Tails installed, the way I will need to follow:
>
> https://tails.boum.org/doc/advanced_topics/virtualization/virt-manager/index.en.html

But there is now the better debian than the systemDestructed Debian,
which is Devuan, and there is now Heads (based on Devuan) instead of
Tails (based on Debian):

https://heads.dyne.org/about.html
or
http://fz474h2o46o2u7xj.onion/about.html

And, as far as Tails, I can use it, although as of this time still only
in pure Qemu (just a little is still missing for full Libvirt deployment
under sound control of grsecurity RBAC policies... more below about
that):
https://www.croatiafidelis.hr/foss/cap/cap-161015-qemu-devuan/qemu-devuan-10.php
(and the successive page)

This was wrong, that's for developers
> So, the mailing list:
>
> https://www.redhat.com/mailman/listinfo/virt-tools-list
>
there's users list instead:
https://www.redhat.com/mailman/listinfo/libvirt-users

But I first need to complete setting up the grsecurity RBAC policies for
Libvirt:

Libvirt virtualization policies
https://forums.grsecurity.net/viewtopic.php?f=5&t=4675

which I might be at an end of (that took time! but it feels
rewarding)...

All of that I have successfully managed to do without dbus...

Or d-bus, like in the comparison table of init systems:

https://wiki.gentoo.org/wiki/Comparison_of_init_systems

Which I hope is slowly spreading from Gentoo into other true-unix FOSS,
the sans-dbus OpenRC...

But I would need time to see, say, how far Devuan has reached in
implementing OpenRC, as they planned...

(I'm not a dev, I'm only yet struggling to become a good
tester for projects that I believe in...)

I have also hit a snag... see the last post at:

Whonix on Gentoo issues
https://forums.whonix.org/t/whonix-on-gentoo-issues/3188/17
where find (pasting:

(virt-viewer:9916): GSpice-CRITICAL **: egl init failed: cannot create
EGL context

and more. That's basically, my virt-manager, virt-viewer and spice, and
spice-gtk and xf86-video-qxl have some issues, and when virt-viewer
starts, the spice client can't get the egl context, which I have come to
understand is the... keyboard and the mouse...

In slow time, if anybody has any advice about this matter, I'll be
greatful!

--
Miroslav Rovis
Zagreb, Croatia
https://www.CroatiaFidelis.hr