November 2019 - openSUSE Users - openSUSE Mailing Lists

[opensuse] xfs planed to be used for root soon?
by L A Walsh 28 Nov '19

28 Nov '19

I was wondering if opensuse was planning to use xfs for its root again, soon? xfs formally has reflink copying and can automatically perform some types of deduplication. It's 1 better than using a hard link since only the data is currently dedupped and 2 copies of the same file can be owned by different people, even though the data is linked. They also have COW, so if you change bytes in the middle, only those bytes need to be written, like 2-1GB files were equal, copied 4k of 1's into the middle of one of the original two files. The space on disk went up by 4k for the new file and its sectors were deduped from the other file. No one would claim perfection, but given the frequent problems with BRTFS, it might yield lower problems. Forgive me if this has already been discussed, but it seemed cool! 'cp' even has support for doing reflnk copies or not. -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

2 1

[opensuse] Squid does not execute squidguard (As it should)
by Rollniak 28 Nov '19

28 Nov '19

Hello everyone, I have some trouble with Squid and SquidGuard on openSUSE 15.1. Apparently squidGuard is not called by squid and does not use the squidGuard database, as a result everything passes the proxy. More details : Tow virtual machines based on OpenSuse leap 15.1 : - A server with Squid and squiguard (Packages: squid squidguard squidguard-doc), the firewall is down for the test. - A client with a GUI and Firefox configured to target the proxy server (Manual configuration). .. Squid configuration files : # # Recommended minimum configuration: # # Example rule allowing access from your local networks. # Adapt to list your (internal) IP networks from where browsing # should be allowed #acl localnet src 0.0.0.1-0.255.255.255 # RFC 1122 "this" network (LAN) #acl localnet src 10.0.0.0/8 # RFC 1918 local private network (LAN) #acl localnet src 100.64.0.0/10 # RFC 6598 shared address space (CGN) #acl localnet src 169.254.0.0/16 # RFC 3927 link-local (directly plugged) machines #acl localnet src 172.16.0.0/12 # RFC 1918 local private network (LAN) #acl localnet src 192.168.0.0/16 # RFC 1918 local private network (LAN) #acl localnet src fc00::/7 # RFC 4193 local private network range #acl localnet src fe80::/10 # RFC 4291 link-local (directly plugged) machines acl localnet src 192.168.122.0/24 acl SSL_ports port 443 acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 # https acl Safe_ports port 70 # gopher acl Safe_ports port 210 # wais acl Safe_ports port 1025-65535 # unregistered ports acl Safe_ports port 280 # http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports port 591 # filemaker acl Safe_ports port 777 # multiling http acl CONNECT method CONNECT acl forbiddenword url_regex shopping facebook # Add pass to squidGuard program url_rewrite_program /usr/sbin/squidGuard -c /etc/squidguard.conf #url_rewrite_children 5 # # Recommended minimum Access Permission configuration: # # Deny requests to certain unsafe ports http_access deny !Safe_ports # Deny CONNECT to other than secure SSL ports http_access deny CONNECT !SSL_ports # Only allow cachemgr access from localhost http_access allow localhost manager http_access deny manager # We strongly recommend the following be uncommented to protect innocent # web applications running on the proxy server who think the only # one who can access services on "localhost" is a local user #http_access deny to_localhost # # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS # http_access deny forbiddenword http_access allow localnet # Example rule allowing access from your local networks. # Adapt localnet in the ACL section to list your (internal) IP networks # from where browsing should be allowed http_access allow localhost # And finally deny all other access to this proxy http_access deny all # Squid normally listens to port 3128 http_port 3128 # Uncomment and adjust the following to add a disk cache directory. #cache_dir ufs /var/cache/squid 100 16 256 # Leave coredumps in the first cache dir coredump_dir /var/cache/squid # # Add any of your own refresh_pattern entries above these. # refresh_pattern ^ftp: 1440 20% 10080 refresh_pattern ^gopher: 1440 0% 1440 refresh_pattern -i (/cgi-bin/|\?) 0 0% 0 refresh_pattern . 0 20% 4320 .. squidguard configuration file # # CONFIG FILE FOR SQUIDGUARD # dbhome /var/lib/squidGuard/db logdir /var/log/squidGuard # # DESTINATION CLASSES: # dest adult { domainlist blacklist/domains urllist blacklist/urls expressionlist blacklist/expressions } dest shopping { domainlist shopping/domains urllist shopping/urls expressionlist shopping/expressions } acl { default { pass !adult !shopping !in-addr any none redirect http://192.168.122.233:/block.html } } I get the shopping list from this url: https://dsi.ut-capitole.fr/blacklists/index_en.php the url_regex works fine, and the squidguard executable does not seem to be called by squid. The logs entry shows only the squidguard launched by hand in my terminal. .. squidguard logs 2019-11-21 14:46:23 [5070] squidGuard 1.4 started (1574343981.465) 2019-11-21 14:46:23 [5070] db update done 2019-11-21 14:46:23 [5070] squidGuard stopped (1574343983.014) 2019-11-21 17:02:34 [7534] New setting: dbhome: /var/lib/squidGuard/db 2019-11-21 17:02:34 [7534] New setting: logdir: /var/log/squidGuard 2019-11-21 17:02:34 [7534] init domainlist /var/lib/squidGuard/db/blacklist/domains 2019-11-21 17:02:34 [7534] loading dbfile /var/lib/squidGuard/db/blacklist/domains.db 2019-11-21 17:02:34 [7534] init urllist /var/lib/squidGuard/db/blacklist/urls 2019-11-21 17:02:34 [7534] loading dbfile /var/lib/squidGuard/db/blacklist/urls.db 2019-11-21 17:02:34 [7534] init expressionlist /var/lib/squidGuard/db/blacklist/expressions 2019-11-21 17:02:34 [7534] init domainlist /var/lib/squidGuard/db/blacklist/shopping 2019-11-21 17:02:34 [7534] loading dbfile /var/lib/squidGuard/db/blacklist/shopping.db 2019-11-21 17:02:34 [7534] squidGuard 1.4 started (1574352154.779) 2019-11-21 17:02:34 [7534] squidGuard ready for requests (1574352154.780) Can you help me to understand why squidguard is not called by squid ? best regards, -- Rollniak -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

2 1

[opensuse] ssh: Connection refused
by Wolfgang Mueller 28 Nov '19

28 Nov '19

Recently I have installed Leap 15.1 on a new computer which I have given the internal address 192.168.2.13 (wicked service, no DHCP). Everything works fine, but the computer is not reachable by ssh. /home/wolfgang> ssh 192.168.2.13 ssh: connect to host 192.168.2.13 port 22: Connection refused How can I make it reachable by ssh? Thanks in advance and best regards, Wolfgang -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

8 16

[opensuse] ssh without password
by Wolfgang Mueller 27 Nov '19

27 Nov '19

In "man ssh" I read: The user creates his/her key pair by running ssh-keygen(1). This stores the private key in [...] ~/.ssh/id_rsa (RSA) and stores the public key in [...] ~/.ssh/id_rsa.pub (RSA) in the user's home directory. The user should then copy the public key to ~/.ssh/authorized_keys in his/her home directory on the remote machine. The authorized_keys file corresponds to the conventional ~/.rhosts file, and has one key per line, though the lines can be very long. After this, the user can log in without giving the password. I followed these instructions. But the remote system still continues asking for a password. Only root can login without specifying a password. Thank you in advance for your help, Wolfgang -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

2 2

[opensuse] cleanups of old kernel builds or /usr/src/kernel(or non-current kerns from /usr/src/linux-[45].x.y..?)
by L A Walsh 26 Nov '19

26 Nov '19

Does anyone know of any cleanups that are done on "old" sources (and builds) of /usr/src/linux-[45]versions? I have my /usr/src pointing to /home/src with /home/src/linux usually pointing into /home/linux/<some version>. Not sure when it happened but something cleaned /home/linux/.... out of all linux source+build dirs going back to about 2012, except for 1-2 dirs from last year. Was very weird -- never had seen such a thorough clean. For me, Nov 01 backup was tainted and I skipped back to my Oct 01 full backup where I could recover the missing 35G. Certainly skipped a heartbeat or two until I fund a substantial backup. I have yet to go through any of the sub-backups in Oct but also don't know if anything else might be missing -- doesn't *seem* to be the case -- so was wondering if there were any scripts that might have been having a bad day running on my system, though that would seem to be a bit of a stretch. Certainly not thinking of any deliberate actions by anybody, since except for the build-configurations, most of it would have been downloadable from kernel.org and rebuilt. Just weird. Versioned-backups really are a life saver sometimes... -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

1 0

[opensuse] setfacl problem
by Carlos E. R. 26 Nov '19

26 Nov '19

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi cer@Telcontar:/data/storage_b/cer> setfacl -m u:wwwrun:rx tmp/ cer@Telcontar:/data/storage_b/cer> setfacl -m u:users:rx tmp/ setfacl: Option -m: Invalid argument near character 3 cer@Telcontar:/data/storage_b/cer> l tmp/ total 4266952 drwxr-xr-x+ 3 cer cer 69 Nov 27 2011 ./ ... Why does one command work and not the other? I jus edited the group name, and both do exist. cer@Telcontar:/data/storage_b/cer> getfacl tmp # file: tmp # owner: cer # group: cer user::rwx user:wwwrun:r-x group::r-x mask::r-x other::r-x cer@Telcontar:/data/storage_b/cer> - -- Cheers Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXd0piRwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVklQAoJD/CSo0Yeug2W6Vbbzj cZC7f95tAJ0eqFr4Xo/SjMnpV0/WxMoNUvyPlw== =YzLT -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

2 2

Re: [opensuse] Re: repomd.xml will expire soon
by Marcus Meissner 25 Nov '19

25 Nov '19

Hi, On Mon, Nov 25, 2019 at 06:47:05AM +0300, Andrei Borzenkov wrote: > > 24 нояб. 2019 г., в 22:37, Marcus Meissner <meissner(a)suse.de> написал(а): > > > > Hi, > > > > The repo key should auto extend itself. (Well the obs will do it.) > > > > We will monitor if this happens. > > > > Is it possible to configure OBS to do it earlier, to avoid zypper warnings? FWIW, the key is now extended until 2022. The repo will get the new key on its next republish. What repository was it actually? The original reporter did not say? Ciao, Marcus -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

2 1

[opensuse] repomd.xml will expire soon
by Wolfgang Mueller 24 Nov '19

24 Nov '19

Invoking 'zypper patch' yielded--among others--the following response: > Retrieving repository 'Untested Updates' metadata----------------[\] > The gpg key signing file 'repomd.xml' will expire in 14 days. > Repository: Untested Updates > Key Name: openSUSE:Maintenance OBS Project <openSUSE:Maintenance@build.opensuse.org> > Key Fingerprint: 7C097045 B0D351D3 69AC453A 598D0E63 B3FD7E48 > Key Created: Fri Sep 29 19:30:59 2017 > Key Expires: Sun Dec 8 18:30:59 2019 (expires in 14 days) > Rpm Name: gpg-pubkey-b3fd7e48-59ce8353 > Retrieving repository 'Untested Updates' metadata.............[done] Is there any need to renew or prolongate the file repomd.xml? Or is it--as I suppose--dispensable? Thanks in advance, Wolfgang -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

4 8

[opensuse] Fwd: Re: [clamav-users] clamav-0.102.1 error - Update
by Frans de Boer 24 Nov '19

24 Nov '19

LS, Just want to give some inside because of the outdated software in openSUSE 15.1. Just fear that 15.2 will not be much better as to up-to-date software. I hope there will be a hybrid someday between the cutting edge (sort off) Tumbleweed and the stable distributions based on very old software. Frans >>> I get the next report (all systems): >>> /configure: line 30094: auto=yes: command not found >>> >>> Also, check_clamav failed on 2 different systems (openSUSE 15.1). It >>> did not failed on openSUSE Tumbleweed. >>> >>> --- Frans. >>> > http://www.clamav.net/contact.html#ml On all my systems using openSUSE Tumbleweed, all tests work as expected. Alas, under openSUSE 15.1 - with it's mostly antiquated software -, which is their newest "recent" stable distribution, does the test "check_clamav" fails. This applies both to clamav-0.102.0 and .1. The clamav-0.101.x series have no such problem. Regards, Frans. -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

5 16

[opensuse] dracut --kernel-cmdline option not effective?
by Istvan Gabor 23 Nov '19

23 Nov '19

Hello: I would like to make an initrd image in openSUSE Leap 15.1 that has root=LABEL=... and resume=LABEL=... kernel command line options instead of root=UUID= and resume=UUID= . When I run mkinitrd it runs as: # mkinitrd Creating initrd: /boot/initrd-4.12.14-lp151.28.13-default dracut: Executing: /usr/bin/dracut --logfile /var/log/YaST2/mkinitrd.log --force /boot/initrd-4.12.14-lp151.28.13-default 4.12.14-lp151.28.13-default ... dracut: *** Store current command line parameters *** dracut: Stored kernel commandline: dracut: resume=UUID=ca1f9a2d-468f-4718-b993-d7041556be8c dracut: root=UUID=c6a2aa57-1ff2-4ebd-a1fb-e56cf4b3a4b9 rootfstype=ext4 rootflags=rw,relatime,data=ordered dracut: *** Creating image file '/boot/initrd-4.12.14-lp151.28.13-default' *** dracut: *** Creating initramfs image file '/boot/initrd-4.12.14-lp151.28.13-default' done *** According to dracut man page I can customize kernel command line options with --kernel-cmdline option to dracut. Based on the above I ran dracut as: # /usr/bin/dracut --kernel-cmdline "root=LABEL=L151-KDE3-ext resume=LABEL=swap-OSL" --logfile /var/log/YaST2/mkinitrd.log --force /boot/initrd-4.12.14-lp151.28.13-default 4.12.14-lp151.28.13-default dracut: Executing: /usr/bin/dracut --kernel-cmdline "root=LABEL=L151-KDE3-ext resume=LABEL=swap-OSL" --logfile /var/log/YaST2/mkinitrd.log --force /boot/initrd-4.12.14-lp151.28.13-default 4.12.14-lp151.28.13-default ... dracut: *** Store current command line parameters *** dracut: Stored kernel commandline: dracut: root=LABEL=L151-KDE3-ext resume=LABEL=swap-OSL dracut: resume=UUID=ca1f9a2d-468f-4718-b993-d7041556be8c dracut: root=UUID=c6a2aa57-1ff2-4ebd-a1fb-e56cf4b3a4b9 rootfstype=ext4 rootflags=rw,relatime,data=ordered dracut: *** Creating image file '/boot/initrd-4.12.14-lp151.28.13-default' *** dracut: *** Creating initramfs image file '/boot/initrd-4.12.14-lp151.28.13-default' done *** It seems that dracut recognizes and applies --kernel-cmdline option values but then overwrites them by the system default values, at least that is how I interpret dracut output messages. What do I do wrong and how could I set only root=LABEL=L151-KDE3-ext and resume=LABEL=swap-OSL kernel command line options in the initrd image? Thanks, Istvan -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

2 4