[CentOS] Ailing MATE desktop

2020-05-04 Thread Robert G (Doc) Savage via CentOS
I need some C8 troubleshooting help with MATE.

I'm building a ZFS storage server with a SuperMicro H11SSL motherboard,
EPYC 7232 CPU, and 32 GB ECC SDRAM.  I installed CentOS 8.1.1911 from
the iso as soon as it was released. I'm using the on-board ASPEED VGA
video. I installed MATE v1.22 from 
https://copr.fedorainfracloud.org/coprs/stenstorp/MATE/. The following
packages are installed:

libmateweather-data-1.24.0-2.el8.noarch
libmatemixer-1.24.0-1.el8.x86_64
mate-desktop-libs-1.24.0-3.el8.x86_64
mate-terminal-1.24.0-2.el8.x86_64
mate-themes-3.22.21-1.el8.noarch
mate-panel-libs-1.22.2-1.el8.x86_64
mate-desktop-1.24.0-3.el8.x86_64
mate-settings-daemon-1.22.1-2.el8.x86_64
mate-polkit-1.24.0-2.el8.x86_64
mate-notification-daemon-1.22.1-1.el8.x86_64
mate-media-1.24.0-2.el8.x86_64
mate-power-manager-1.22.2-1.el8.x86_64
mate-system-log-1.22.2-2.el8.x86_64
libmateweather-1.24.0-2.el8.x86_64
libmatekbd-1.24.0-1.el8.x86_64
mate-utils-common-1.22.2-2.el8.noarch
mate-disk-usage-analyzer-1.22.2-2.el8.x86_64
mate-user-guide-1.24.0-1.el8.noarch
mate-menus-preferences-category-menu-1.24.0-2.el8.x86_64
mate-dictionary-1.22.2-2.el8.x86_64
mate-menus-1.24.0-2.el8.x86_64
mate-session-manager-1.24.0-1.el8.x86_64
mate-backgrounds-1.24.0-1.el8.noarch
mate-search-tool-1.22.2-2.el8.x86_64
mate-panel-1.22.2-1.el8.x86_64
mate-system-monitor-1.24.0-1.el8.x86_64
mate-applets-1.24.0-2.el8.x86_64
mate-control-center-1.22.2-2.el8.x86_64
mate-icon-theme-1.24.0-1.el8.noarch
mate-control-center-filesystem-1.22.2-2.el8.x86_64
mate-menus-libs-1.24.0-2.el8.x86_64
mate-user-admin-1.5.1-3.el8.x86_64
mate-calc-1.24.0-2.el8.x86_64
mate-screenshot-1.22.2-2.el8.x86_64
mate-screensaver-1.24.0-2.el8.x86_64

About two weeks ago following a reset, after a normal login an
incomplete MATE desktop appeared. The background is black. There is no
visible mouse, although there is some ghostly pixel movement in the top
toolbar when what should be the mouse cursor floats over each of those
toolbar icons. I can hit Enter and start whatever app the ghost cursor
is over, and the mouse works only within that app's window. 

I'm a long-time user of MATE ever since GNOME3 was released, but until
now I've never had any problems with it. I have no idea where to start
troubleshooting. I've looked in journalctl, systemctl, and dmesg, but
found nothing obvious. There's nothing in the MATE wiki  to help.

I'm open to any suggestions where to start looking.

--Doc Savage
 Fairview Heights, IL
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Jitsi Meet on CentOS 7 ?

2020-05-04 Thread Erick Perez - Quadrian Enterprises
Hi Centos friends.
I had some time to write a spartan tutorial on running the latest stable
Jitsi Video Bridge and Jitsi Meet and Centos 7.7.
I wrote it while testing it so this WORKS and I am currently using it for
fun with the kids.

I do have the server currently running but blocked by my firewall. I am
willing to allow a few of the people such a Kovacs and others to connect to
my Jitsi server to test usability. But this is a 1CPU/2GBRAM VM in vultr.com
so we cannot expect premium video quality and maybe no more than 10 people
at the same time.

Do note that in order to provide access, I need an IP and will open the
server to connect from that IP.

My Wordpress template is not the best so sorry for the formatting. I Will
work on that tomorrow.

here is the tutorial
https://www.nubeinterna.com/2020/05/03/centos-7-7-and-jitsi/

hope it helps.



On Sun, May 3, 2020 at 12:11 PM Nicolas Kovacs  wrote:

> Le 03/05/2020 à 18:07, H a écrit :
> > I am also interested in installing Jitsi server on CentOS 7, as well as
> > running the desktop app on C7.
>
> According to the Jitsi developers, you shouldn't even use that and prefer
> using
> a browser.
>
> Though I'd take that information with a grain of salt, because the
> developer I
> talked to yesterday on IRC called my browser (Firefox 68.7.0 ESR)
> "hopelessly
> obsolete".
>
> Have you ever tried to explain concepts like long term support and
> Enterprise
> Linux to a 20 year old Arch user ?
>
> Here in France we call that "pissing in a violin". :o)
>
> Cheers,
>
> Niki
>
> --
> Microlinux - Solutions informatiques durables
> 7, place de l'église - 30730 Montpezat
> Site : https://www.microlinux.fr
> Mail : i...@microlinux.fr
> Tél. : 04 66 63 10 32
> Mob. : 06 51 80 12 12
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>


-- 

-
Erick Perez
Quadrian Enterprises S.A. - Panama, Republica de Panama
Skype chat: eaperezh
WhatsApp IM: +507-6675-5083
-
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Understanding VDO vs ZFS

2020-05-04 Thread John Pierce
Rather than dedupe at the file system level, I found the application level
dedupe in BackupPC works really well...   I've run BackupPC on both a big
ZFS volume, and on a giant XFS over LVM over MDRAID volume (24 x 3TB disks
organized as 2 x 11 raid6 plus 2 hot spares).   The backuppc server I built
at my last $job had 30 days of daily incrementals and 12 months of
monthlies of about 25 servers+VMs (including Linux, Solaris, AIX, and
Windows).   The dedupe is done globally on a file level, so no matter how
many instances of a file in all those backups ((30+12) * 25), there's only
one file in the 'hive'.Bonus, BackupPC has a nice web UI for retrieving
backups, I could create accounts for my various developers, and they could
retrieve stuff from any covered date on any of the servers they had access
to without my intervention.

about the only manual intervention I ever needed to do over the several
years this was running involved the Windows rsync client needing a PID file
deleted after an unexpected reboot.





-- 
-john r pierce
  recycling used bits in santa cruz
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Understanding VDO vs ZFS

2020-05-04 Thread Jeffrey Walton
On Sat, May 2, 2020 at 10:54 PM david  wrote:
>
> I'm looking for a solution for backups because ZFS has failed on me
> too many times.  In my environment, I have a large amount of data
> (around 2tb) that I periodically back up.  I keep the last 5
> "snapshots".  I use rsync so that when I overwrite the oldest backup,
> most of the data is already there and the backup completes quickly,
> because only a small number of files have actually changed.

Duplicity works well on CentOS. I had to perform a restore of a
website and wiki after I [accidentally] deleted both. Backups are to
another machine over SSH scheduled through Systemd.

A Duplicity-based backup may help protect your data until you get
something in place you like better.

Jeff
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Understanding VDO vs ZFS

2020-05-04 Thread Andrew Walsh
On Mon, May 4, 2020 at 10:02 AM Stefan S  wrote:
>
> Hi David,
>
> in my opinion, VDO isn't worth the effort. I tried VDO for the same use case: 
> backups. My dataset is 2-3TB and I backup daily. Even with a smaller dataset, 
> VDO couldn't stand up to it's promises. It used tons of CPU and memory and 
> with a lot of tuning I could get it to kind of work, but it became corrupted 
> at the slightest problem (even a shutdown could do this, and shutdowns could 
> also take hours).

I'm sorry to hear you feel that way.  I would be interested to
understand the situations that you experienced this problem so that it
can be addressed better in the future.  Did you reach out for any
guidance when it was happening?

>
> I have tried a number of things and I use a combination of two things now:
> 1. a btrfs volume with force-compress enabled to store the intermediate data 
> - it compresses my data to about 60% and that's enough for me
> 2. use of bup (https://bup.github.io/) to store long-term backups.
>
> bup is incredibly efficient for my use case (full VM backups). Over the 
> course of a whole month, the dataset only increases by about 30% from the 
> initial size (I create a new full backup each month) - and this is with FULL 
> backups of all VMs every day. bup backupsets can also be mounted via FUSE, 
> giving you access to all stored versions in a filesystem-like manner.
>
> If you can backup at will you can probably forego the btrfs volume for 
> intermediate storage - that is just a band-aid to work around a specific 
> issue here.
>
>
> Stefan
>
>
> --
>
> 
> From: CentOS  on behalf of david 
> Sent: Sunday, May 3, 2020 2:50 AM
> To: centos@centos.org 
> Subject: [CentOS] Understanding VDO vs ZFS
>
> Folks
>
> I'm looking for a solution for backups because ZFS has failed on me
> too many times.  In my environment, I have a large amount of data
> (around 2tb) that I periodically back up.  I keep the last 5
> "snapshots".  I use rsync so that when I overwrite the oldest backup,
> most of the data is already there and the backup completes quickly,
> because only a small number of files have actually changed.
>
> Because of this low change rate, I have used ZFS with its
> deduplication feature to store the data.  I started using a Centos-6
> installation, and upgraded years ago to Centos7.  Centos 8 is on my
> agenda.  However, I've had several data-loss events with ZFS where
> because of a combination of errors and/or mistakes, the entire store
> was lost.  I've also noticed that ZFS is maintained separately from
> Centos.  At this moment, the Centos 8 update causes ZFS to
> fail.  Looking for an alternate, I'm trying VDO.
>
> In the VDO installation, I created a logical volume containing two
> hard-drives, and defined VDO on top of that logical volume.  It
> appears to be running, yet I find the deduplication numbers don't
> pass the smell test.  I would expect that if the logical volume
> contains three copies of essentially identical data, I should see
> deduplication numbers close to 3.00, but instead I'm seeing numbers
> like 1.15.  I compute the compression number as follows:
>   Use df and extract the value for "1k blocks used" from the third column
>   use vdostats --verbose and extract the number titled "1K-blocks used"
>
> Divide the first by the second.
>
> Can you provide any advice on my use of ZFS or VDO without telling me
> that I should be doing backups differently?
>
> Thanks
>
> David
>
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Understanding VDO vs ZFS

2020-05-04 Thread Andrew Walsh
On Sat, May 2, 2020 at 10:54 PM david  wrote:
>
> Folks
>
> I'm looking for a solution for backups because ZFS has failed on me
> too many times.  In my environment, I have a large amount of data
> (around 2tb) that I periodically back up.  I keep the last 5
> "snapshots".  I use rsync so that when I overwrite the oldest backup,
> most of the data is already there and the backup completes quickly,
> because only a small number of files have actually changed.
>
> Because of this low change rate, I have used ZFS with its
> deduplication feature to store the data.  I started using a Centos-6
> installation, and upgraded years ago to Centos7.  Centos 8 is on my
> agenda.  However, I've had several data-loss events with ZFS where
> because of a combination of errors and/or mistakes, the entire store
> was lost.  I've also noticed that ZFS is maintained separately from
> Centos.  At this moment, the Centos 8 update causes ZFS to
> fail.  Looking for an alternate, I'm trying VDO.
>
> In the VDO installation, I created a logical volume containing two
> hard-drives, and defined VDO on top of that logical volume.  It
> appears to be running, yet I find the deduplication numbers don't
> pass the smell test.  I would expect that if the logical volume
> contains three copies of essentially identical data, I should see
> deduplication numbers close to 3.00, but instead I'm seeing numbers
> like 1.15.  I compute the compression number as follows:
>   Use df and extract the value for "1k blocks used" from the third column
>   use vdostats --verbose and extract the number titled "1K-blocks used"

I'd like to know what kind of data you're looking to back up (that
will just help get an idea of whether it's even a good fit for dedupe;
though if it dedupes well on ZFS, it probably is fine).  I'd also like
to know how you configured your VDO volume (provide the 'vdo create'
command you used).  As mentioned in some other responses, can you
provide vdostats (full 'vdostats --verbose' output as well as base
'vdostats') and df outputs for this volume?  That would help
understand a bit more on what you're experiencing.

The default deduplication window for a VDO volume is set to ~250G
(--indexMem=0.25).  Assuming you're writing the full 2T of data each
time and want to achieve deduplication across that entire 2T of data,
it would require a "--indexMem=2G" configuration.  You may want to
account for growth as well, which means you may want to consider a
larger amount of memory for the '--indexMem' parameter.  An
alternative, if memory isn't as plentiful, you could enable the sparse
index option to cover a significantly larger dedupe window for a
smaller amount of memory commitment.  There is an additional on-disk
footprint requirement that goes with it.  You can look at the
documentation [0] to find out those specific requirements.  For this
setup, a sparse index with default memory footprint (0.25G) would
cover ~2.5T, but would require an additional ~20G of storage over the
default index configuration.

[0] 
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/deduplicating_and_compressing_storage/deploying-vdo_deduplicating-and-compressing-storage#vdo-memory-requirements_vdo-requirements

>
> Divide the first by the second.
>
> Can you provide any advice on my use of ZFS or VDO without telling me
> that I should be doing backups differently?

Without more information about what you're attempting to do, I can't
really say that what you're doing is wrong, but I also can't say that
there are any expectations from VDO yet that aren't being met.  More
context would certainly help get to the bottom of this question.

>
> Thanks
>
> David
>
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Understanding VDO vs ZFS

2020-05-04 Thread Stefan S
Hi David,

in my opinion, VDO isn't worth the effort. I tried VDO for the same use case: 
backups. My dataset is 2-3TB and I backup daily. Even with a smaller dataset, 
VDO couldn't stand up to it's promises. It used tons of CPU and memory and with 
a lot of tuning I could get it to kind of work, but it became corrupted at the 
slightest problem (even a shutdown could do this, and shutdowns could also take 
hours).

I have tried a number of things and I use a combination of two things now:
1. a btrfs volume with force-compress enabled to store the intermediate data - 
it compresses my data to about 60% and that's enough for me
2. use of bup (https://bup.github.io/) to store long-term backups.

bup is incredibly efficient for my use case (full VM backups). Over the course 
of a whole month, the dataset only increases by about 30% from the initial size 
(I create a new full backup each month) - and this is with FULL backups of all 
VMs every day. bup backupsets can also be mounted via FUSE, giving you access 
to all stored versions in a filesystem-like manner.

If you can backup at will you can probably forego the btrfs volume for 
intermediate storage - that is just a band-aid to work around a specific issue 
here.


Stefan


--


From: CentOS  on behalf of david 
Sent: Sunday, May 3, 2020 2:50 AM
To: centos@centos.org 
Subject: [CentOS] Understanding VDO vs ZFS

Folks

I'm looking for a solution for backups because ZFS has failed on me
too many times.  In my environment, I have a large amount of data
(around 2tb) that I periodically back up.  I keep the last 5
"snapshots".  I use rsync so that when I overwrite the oldest backup,
most of the data is already there and the backup completes quickly,
because only a small number of files have actually changed.

Because of this low change rate, I have used ZFS with its
deduplication feature to store the data.  I started using a Centos-6
installation, and upgraded years ago to Centos7.  Centos 8 is on my
agenda.  However, I've had several data-loss events with ZFS where
because of a combination of errors and/or mistakes, the entire store
was lost.  I've also noticed that ZFS is maintained separately from
Centos.  At this moment, the Centos 8 update causes ZFS to
fail.  Looking for an alternate, I'm trying VDO.

In the VDO installation, I created a logical volume containing two
hard-drives, and defined VDO on top of that logical volume.  It
appears to be running, yet I find the deduplication numbers don't
pass the smell test.  I would expect that if the logical volume
contains three copies of essentially identical data, I should see
deduplication numbers close to 3.00, but instead I'm seeing numbers
like 1.15.  I compute the compression number as follows:
  Use df and extract the value for "1k blocks used" from the third column
  use vdostats --verbose and extract the number titled "1K-blocks used"

Divide the first by the second.

Can you provide any advice on my use of ZFS or VDO without telling me
that I should be doing backups differently?

Thanks

David

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] perl Net::Interface module on CentOS 8

2020-05-04 Thread Werf, C.G. van der (Carel)
Wasn't this renamed to :

perl-IO-Interface (in centos7)

??

Carel van der Werf

-Original Message-
From: CentOS  On Behalf Of Jonathan Billings
Sent: Sunday, 3 May, 2020 23:01
To: CentOS mailing list 
Subject: Re: [CentOS] perl Net::Interface module on CentOS 8

On May 3, 2020, at 14:34, sthustfo  wrote:
> 
> We have received a perl program that makes use of "Net::Interface" 
> module which I am trying to run on CentOS 8. However, running into 
> issues as this module is not found.
> 
> use Net::Interface;
> 
> I could use cpan to install the same, but currently using the rpm 
> packages for all the needs. Any idea which rpm package provides this perl 
> module?

There are no CentOS 8packages that provide that Perl module, I don’t see 
packages in C7 either (nor in EPEL). 

I suggest packaging them yourself. The rpm-build package has an rpmdev-newspec 
command that can take a -t perl argument to create a spec file from a template 
for a perk module. So `rpmdev-newspec -t perl perl-Net-Interface` 

--
Jonathan Billings


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Understanding VDO vs ZFS

2020-05-04 Thread Erick Perez - Quadrian Enterprises
Strahil,
I am using about 1012MB for the first ISO. I believe it's because of
compression. From there vdostats --hu reports 5.0G usage and 12% in
percentage. With savings of 89% for original + 9 copies of the same ISO.


On Sun, May 3, 2020 at 1:17 AM Strahil Nikolov 
wrote:

> On May 3, 2020 8:33:33 AM GMT+03:00, Erick Perez - Quadrian Enterprises <
> epe...@quadrianweb.com> wrote:
> >sorry corrections:
> >For this test I created a 40GB lvm volume group with /dev/sdb and
> >/dev/sdc
> >then a 40GB LV
> >then a 60GB VDO vol (for testing purposes)
> >
> >vdostats --verbose /dev/mapper/vdoas | grep -B6 'saving percent'
> >output from just created vdoas
> >
> >[root@localhost ~]# vdostats --verbose /dev/mapper/vdoas | grep -B6
> >'saving
> >percent'
> >physical blocks : 10483712
> >  logical blocks  : 15728640
> >  1K-blocks   : 41934848
> >  1K-blocks used  : 4212024
> >  1K-blocks available : 37722824
> >  used percent: 10
> >  saving percent  : 99
> >[root@localhost ~]#
> >
> >FIRST copy CentOS-7-x86_64-Minimal-2003.iso (1.1G) to vdoas from source
> >outside vdo volume
> >[root@localhost ~]# vdostats --verbose /dev/mapper/vdoas | grep -B6
> >'saving
> >percent'
> >  1K-blocks used  : 4721348
> >  1K-blocks available : 37213500
> >  used percent: 11
> >  saving percent  : 9
> >
> >SECOND copy  CentOS-7-x86_64-Minimal-2003.iso (1.1G) to vdoas form
> >source
> >outside vdo volume
> >#cp /root/CentOS-7-x86_64-Minimal-2003.iso
> >/mnt/vdomounts/CentOS-7-x86_64-Minimal-2003-version2.iso
> >  1K-blocks used  : 5239012
> >  1K-blocks available : 36695836
> >  used percent: 12
> >  saving percent  : 52
> >
> >THIRD  copy  CentOS-7-x86_64-Minimal-2003.iso (1.1G) to
> >vdoas form inside vdo volume to inside vdo volume
> >  1K-blocks used  : 5248060
> >  1K-blocks available : 36686788
> >  used percent: 12
> >  saving percent  : 67
> >
> >Then I did this a total of 9 more times to have 10 ISOs copied. Total
> >data
> >copied 10.6GB.
> >
> >
> >Do note this:
> >When using DF, it will show the VDO size, in my case 60G
> >when using vdostats it will show the size of the LV, in my case 40G
> >Remeber dedupe AND compression are enabled.
> >
> >The df -hT output shows the logical space occupied by these iso files
> >as
> >seen by the filesystem on the VDO volume.
> >Since VDO manages a logical to physical block map, df sees logical
> >space
> >consumed according to the file system that resides on top of the VDO
> >volume.
> >vdostats --hu is viewing the physical block device as managed by VDO.
> >Physically a single .ISO image is residing on the disk, but logically
> >the
> >file system thinks there are 10 copies, occupying 10.6GB.
> >
> >So at the end I have 10 .ISOs of 1086 1MB blocks (total 10860 1MB
> >blocks)
> >that yield these results:
> >  1K-blocks used  : 5248212
> >  1K-blocks available : 36686636
> >  used percent: 12
> >  saving percent  : 89
> >
> >So at the end it is using 5248212 1K blocks minus  4212024  initial
> >used 1K
> >blocks, gives (5248212 - 4212024) = 1036188 1K blocks / 1024 = about
> >1012MB
> >total.
> >
> >Hope this helps understanding where the space goes.
> >
> >BTW: Testing system is CentOS Linux release 7.8.2003 stock. with only
> >"yum
> >install vdo kmod-kvdo"
> >
> >History of commands:
> >[root@localhost vdomounts]# history
> >2  pvcreate /dev/sdb
> >3  pvcreate /dev/sdc
> >8  vgcreate -v -A y vgvol01 /dev/sdb /dev/sdc
> >9  vgdisplay
> >   13  lvcreate -l 100%FREE -n lvvdo01 vgvol01
> >   14   yum install vdo kmod-kvdo
> >   18  vdo create --name=vdoas --device=/dev/vgvol01/lvvdo01
> >--vdoLogicalSize=60G --writePolicy=async
> >   19  mkfs.xfs -K /dev/mapper/vdoas
> >   20  ls /mnt
> >   21  mkdir /mnt/vdomounts
> >   22  mount /dev/mapper/vdoas /mnt//vdomounts/
> >   26  vdostats --verbose /dev/mapper/vdoas | grep -B6 'saving percent'
> >   28  cp /root/CentOS-7-x86_64-Minimal-2003.iso /mnt/vdomounts/ -vvv
> >   29  vdostats --verbose /dev/mapper/vdoas | grep -B6 'saving percent'
> >   30  cp /root/CentOS-7-x86_64-Minimal-2003.iso
> >/mnt/vdomounts/CentOS-7-x86_64-Minimal-2003-version2.iso
> >   31  vdostats --verbose /dev/mapper/vdoas | grep -B6 'saving percent'
> >   33  cd /mnt/vdomounts/
> >   35  cp CentOS-7-x86_64-Minimal-2003-version2.iso
> >./CentOS-7-x86_64-Minimal-2003-version3.iso
> >   36  vdostats --verbose /dev/mapper/vdoas | grep -B6 'saving percent'
> >   37  df
> >   39  vdostats --hu
> >   40  ls -l --block-size=1MB /root/CentOS-7-x86_64-Minimal-2003.iso
> >   41  df -hT
> >   42  vdo status |