Discuss

discuss@lists.centos.org

2 participants
34758 discussions

vlc: changing volume setting of vlc changes master volume of kmix
by g 22 Sep '15

22 Sep '15

greetings, using: CentOS 6.7 current KDE 4.3.4 VLC media player 2.0.8 Twoflower KMix 3.5 this problem started happening last week. any changing of volume setting of vlc changes master volume of kmix. logging out of kde does not correct. rebooting does. anyone else see this or know of solution? tia. -- peace out. If Bill Gates got a dime for every time Windows crashes... ...oh, wait. He does. THAT explains it! -+- in a world with out fences, who needs gates. CentOS GNU/Linux 6.7 tc,hago. g .

1 0

Re: [CentOS] CentOS6 - Break in attempt? What is the Exploit?
by James B. Byrne 22 Sep '15

22 Sep '15

On Mon, September 21, 2015 15:37, m.roth(a)5-cent.us wrote: > Gordon Messmer wrote: >> >>> > In other words, the >>> >hostkeys would be identical. >> >> I think what the error indicates is that a client tried to connect >> to SSH, and the host key there did not match the fingerprint in the >> client's "known_hosts" database. >> >>> It seems to me that someone attempted an ssh connection while >>> spoofing our internal address. Is such a thing even possible? >>> If so then how does it work? >> >> In the situation as you've described it, probably not. >> >> It would be best to go to your logs themselves for the full >>> log entry and context, rather than relying on a report that >>> summarizes log entries. > > Looks like someone trying to break in. You *are* running fail2ban, are > you not? If not, you need to install and fire it up, now. Yes, we run fail2ban. No, fail2ban did not catch this because the number of attempts was below the threshold for a single IP. The logwatch message reported is incomplete. Our address was the destination address. The source address was not reported by logwatch but it was logged in the syslog and it was not an internal address. It did belong to an organisation that bills itself as "a leader in enterprise security. . .". We have contacted them requesting an explanation of the probe. It could have been an error on someone's part. I suppose. We see a lot of cracker traffic from Chile, Romania, Russia and the Ukraine. China was such a PITA that eventually we simply cut off that range of addresses from reaching us by any ports other than 25/80/443 so we do not even see it any more, except via proxy. Taiwan is nearly in the same boat and Vietnam is next in the queue. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail James B. Byrne mailto:ByrneJB@Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3

1 0

Re: [CentOS] Centos 6.6, apparent xfs corruption
by Nicholas Geovanis 22 Sep '15

22 Sep '15

James Peltier wrote: > Do you have any XFS optimizations enabled in /etc/fstab such logbsize, nobarrier, etc? None. > is the filesystem full? What percentage of the file system is availabl e? There are 2 xfs filesystems: /dev/mapper/vg_gries01-LogVol00 3144200 1000428 2143773 32% /opt/splunk /dev/mapper/vg_gries00-LogVol00 307068 267001 40067 87% /opt/splunk/hot You'll notice that the larger just crossed the 1TB boundary. Thanks.....Nick Geovanis

1 0

Centos 6.6, apparent xfs corruption
by Nicholas Geovanis 21 Sep '15

21 Sep '15

Hi all - After several months of worry-free operation, we received the following kernel messages about an xfs filesystem running under CentOS 6.6. The proximate causes appear to be "Internal error xfs_trans_cancel" and "Corruption of in-memory data detected. Shutting down filesystem". The filesystem is back up, mounted, appears to be working OK underlying a Splunk datastore. Does anyone have a suggestion on diagnosis or known problems? Many thanks.....Nick Geo Sep 18 20:35:15 gries kernel: XFS (dm-2): Internal error xfs_trans_cancel at line 1948 of file fs/xfs/xfs_trans.c. Caller 0xffffffffa01f1388 Sep 18 20:35:15 gries kernel: Sep 18 20:35:15 gries kernel: Pid: 24005, comm: splunkd Not tainted 2.6.32-504.8.1.el6.x86_64 #1 Sep 18 20:35:15 gries kernel: Call Trace: Sep 18 20:35:15 gries kernel: [<ffffffffa01d57bf>] ? xfs_error_report+0x3f/0x50 [xfs] Sep 18 20:35:15 gries kernel: [<ffffffffa01f1388>] ? xfs_rename+0x2d8/0x720 [xfs] Sep 18 20:35:15 gries kernel: [<ffffffffa01f2e55>] ? xfs_trans_cancel+0xf5/0x120 [xfs] Sep 18 20:35:15 gries kernel: [<ffffffffa01f1388>] ? xfs_rename+0x2d8/0x720 [xfs] Sep 18 20:35:15 gries kernel: [<ffffffff8114eef9>] ? __do_fault+0x469/0x530 Sep 18 20:35:15 gries kernel: [<ffffffffa02050d6>] ? xfs_vn_rename+0x66/0x70 [xfs] Sep 18 20:35:15 gries kernel: [<ffffffff8119d149>] ? vfs_rename+0x419/0x480 Sep 18 20:35:15 gries kernel: [<ffffffff8119fab9>] ? sys_renameat+0x309/0x3a0 Sep 18 20:35:15 gries kernel: [<ffffffff8128c295>] ? _atomic_dec_and_lock+0x55/0x80 Sep 18 20:35:15 gries kernel: [<ffffffff811b07e0>] ? mntput_no_expire+0x30/0x110 Sep 18 20:35:15 gries kernel: [<ffffffff810e5c87>] ? audit_syscall_entry+0x1d7/0x200 Sep 18 20:35:15 gries kernel: [<ffffffff8119fb6b>] ? sys_rename+0x1b/0x20 Sep 18 20:35:15 gries kernel: [<ffffffff8100b072>] ? system_call_fastpath+0x16/0x1b Sep 18 20:35:15 gries kernel: XFS (dm-2): xfs_do_force_shutdown(0x8) called from line 1949 of file fs/xfs/xfs_trans.c. Return address = 0xffffffffa01f2e6e Sep 18 20:35:15 gries kernel: XFS (dm-2): Corruption of in-memory data detected. Shutting down filesystem Sep 18 20:35:15 gries kernel: XFS (dm-2): Please umount the filesystem and rectify the problem(s) Sep 18 20:35:27 gries kernel: XFS (dm-2): xfs_log_force: error 5 returned.

3 2

CentOS6 - Break in attempt? What is the Exploit?
by James B. Byrne 21 Sep '15

21 Sep '15

This morning's log review revealed this sshd log entry on one of our web services hosts: Received disconnect: 11: disconnected by user : 2 Time(s) 3: com.jcraft.jsch.JSchException: reject HostKey: 216.185.71.170 : 1 Time(s) The IP address used is that of a public facing database query page for our freight transit information. It is itself a virtual IP address hosted on the system reporting the error. In other words, if this were a legitimate connection then the situation would be that of an ssh client connecting to an sshd server running on the same host albeit each using a different IP address. In other words, the hostkeys would be identical. It seems to me that someone attempted an ssh connection while spoofing our internal address. Is such a thing even possible? If so then how does it work? What is com.jcraft.jsch? -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail James B. Byrne mailto:ByrneJB@Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3

4 3

android sdk on centos7 64-bit.
by Jason Welsh 21 Sep '15

21 Sep '15

trying to use the android sdk on centos 7 and cant seem to find the 32bit libs.. [jason@centos7 platform-tools]$ ./adb devices -bash: ./adb: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory [jason@centos7 platform-tools]$ whats the right way to isntall the needed 32bit libs? I cant seem to find them with yum provides.. Ive tried multilib_policy=best in my yum.conf as well. Jason

4 10

Re: [CentOS] CentOS-6 Logwatch 7.3.6 behaviour
by James B. Byrne 21 Sep '15

21 Sep '15

On Sat, September 19, 2015 06:51, Tony Mountifield wrote: > In article > <d0000782c236fbee71045dad24a43def.squirrel(a)webmail.harte-lyne.ca>, James B. Byrne <byrnejb(a)harte-lyne.ca> wrote: >> After some experimenting I have observed that overriding settings from >> /usr/share/logwatch/default.conf/logwatch.conf in >> /etc/logwatch/conf/logwatch.conf does not produce consistent >> results. >> For example, if I replace the default detail configuration in >> etc/logwatch/conf/logwatch.conf with: >> Detail = High >> It does indeed change the level of detail from the default Low set in >> /usr/share/logwatch/default.conf/logwatch.conf. >> However, if I comment out the line: >> #Service = "-zz-sys" # Prevents execution of zz-sys service in the overridden file then the fact that this line remains in the default.conf version means that the sservice cannot be enabled to run >> by default without editing >> /usr/share/logwatch/default.conf/logwatch.conf. Of course doing that >> means that any update clobbers the local changes. > Can you just add it back in /etc/logwatch/conf/logwatch.conf with: Service = "zz-sys" > I haven't tried it, but it looks like Service lines are cumulative. /usr/sbin/logwatch --range 'today' --mailto support(a)harte-lyne.ca --service zz-runtime --service All Wrong configuration entry for "Service", if "All" selected, only "-" items are allowed As shown above, if you pass '--service All' then any later '--service X' option must be prefaced with a '-' ('--service -X'). In other words, once All is selected then one can only remove selected services. In the config files this is the order used: # The 'Service' option expects either the name of a filter # (in /usr/share/logwatch/scripts/services/*) or 'All'. # The default service(s) to report on. This should be left as All for # most people. Service = All # You can also disable certain services (when specifying all) Service = "-zz-network" # Prevents execution of zz-network service, which # prints useful network configuration info. Service = "-zz-sys" # Prevents execution of zz-sys service, which # prints useful system configuration info. Service = "-eximstats" # Prevents execution of eximstats service, which # is a wrapper for the eximstats program. So, no, one cannot restore a service that is deleted from the run in default.conf by adding it back to the local config file. I can understand what is happening here. The implementation of user config files is conceived as being additive to the default configuration. Anything not specified in /etc/logwatch/conf/logwatch.conf is picked up from /usr/share/logwatch/default.conf/logwatch.conf. Anything in /usr/share/logwatch/default.conf/logwatch.conf is overridden by any similar entry in an earlier config. This implies that the order of processing is: /etc/logwatch/conf/logwatch.conf /usr/share/logwatch/dist.conf /usr/share/logwatch/default.conf/logwatch.conf This seems to be something that needs to be fixed in the default.conf/logwatch.conf file. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail James B. Byrne mailto:ByrneJB@Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3

1 0

Setting up BackupPC on CentOS-7
by Timothy Murphy 21 Sep '15

21 Sep '15

I'd be interested in any corrections or comments on the following instructions (basically for myself): We assume that BackupPC has been installed: sudo yum install BackupPC 1. BackupPC must be run by the user backuppc. Accordingly the lines User apache Group apache in /etc/httpd/conf/httpd.conf should be changed to User backuppc Group backuppc 2. The user backuppc must be able to ssh to root (to run rsync), since only root can access all the files on the system. This is slightly complicated because backuppc has no default shell. $ su Passwd: # su -s /bin/sh backuppc sh-4.1$ cd sh-4.1$ ssh-keygen Generating public/private rsa key pair. sh-4.1$ cd .ssh sh-4.1$ cp id_rsa.pub /tmp sh-4.1$ exit # cd # ls .ssh If .ssh exists and contains id_rsa and id_rsa.pub ignore the next command # ssh-keygen Generating public/private rsa key pair. # cd .ssh # cat /tmp/id_rsa.pub >> authorized_keys # su -s /bin/sh backuppc sh-4.1$ ssh -l root helen helen is the name of my server - substitute the correct name or IP address # exit sh-4.1$ exit # 3. We must setup the graphic interface to BackupPC, since it is more or less impossible to administer BackupPC otherwise. I want to configure BackupPC from my laptop. My laptop and server are on the same network 192.168.2.0 # vi /etc/httpd/conf.d/BackupPC.conf Firstly, after the line allow from 127.0.0.1 add allow from 192.168.2.0/255.255.255.0 (giving the IP address of your network in place of 192.168.2.0). Secondly, change the line Require local to Require ip 192.168.2.0/255.255.255.0 127.0.0.1 4. Give backuppc and yourself passwords to access BackupPC # htpasswd -c /etc/BackupPC/apache.users backuppc Password: # htpasswd -c /etc/BackupPC/apache.users yourusername Password: # exit 5. Ensure that all BackupPC files are owned by backuppc.apache # chown -R backuppc.apache /etc/BackupPC /etc/httpd/conf.d/BackupPC.conf /var/lib/BackupPC 6. Restart BackupPC and apache # systemctl restart backuppc # systemctl restart httpd 7. Now see if you can access BackupPC on your server: Browse to http://localhost/backuppc If this succeeds give username backuppc and the password you chose for yourself above 8. Now try the same on your laptop: Browse to http://helen/backuppc (substituting your server's name or IP address for "helen"). Again give username backuppc and the password you chose for yourself above. 9. Returning to the server, # cd /etc/BackupPC # vi hosts I appended the line helen 0 backuppc to this file - you can choose any name here in place of helen it does not have to be the name of your server. 10. Now browse again to BackupPC, on laptop or server. Where it says "Select a host" give the name you just chose. Click on "Edit Config" and then on "Xfer" and in the RsyncShareName line add the directory or directories on your server that you want to backup, and then click on Save. (I chose /Photos, /common/tim and /var/www, but of course this is entirely up to you.) Click on "helen Home" (substituting the name you chose above), and press "Start full backup". -- Timothy Murphy gayleard /at/ eircom.net School of Mathematics, Trinity College, Dublin

3 3

CentOS-6 Logwatch 7.3.6 behaviour
by James B. Byrne 19 Sep '15

19 Sep '15

After some experimenting I have observed that overriding settings from /usr/share/logwatch/default.conf/logwatch.conf in /etc/logwatch/conf/logwatch.conf does not produce consistent results. For example, if I replace the default detail configuration in etc/logwatch/conf/logwatch.conf with: Detail = High It does indeed change the level of detail from the default Low set in /usr/share/logwatch/default.conf/logwatch.conf. However, if I comment out the line: #Service = "-zz-sys" # Prevents execution of zz-sys service in the overridden file then the fact that this line remains in the default.conf version means that the sservice cannot be enabled to run by default without editing /usr/share/logwatch/default.conf/logwatch.conf. Of course doing that means that any update clobbers the local changes. I am not sure if this a bug or a design feature but it seems to me that on should be able to override all of the default settings for services. The only way around this seems to be to specify '--service All' on the command line. But then the service entries in logwatch.conf seem to be ignored entirely so that one must also specify the service exclusions on the command line. I also ran across a rather bizarre 'feature' with the 'DisplayOrder' setting. Evidently, if one gives the same DisplayOrder value to two or more services (say zz-sys which has DisplayOrder = 0.4 and zz-runtime which uses the default value of 0.5 otherwise) then only the last service (ordered alphabetically) is reported. No errors are logged or conflict notices are given either. The other service reports just 'disappear'. However, one can explicitly assign multiple services a DisplayOrder value of 0.5 and all are reported nonetheless, in alphabetic order, along with the other services which simply take the implicit default value. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail James B. Byrne mailto:ByrneJB@Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3

2 1

BackupPC is not easy to setup
by Timothy Murphy 18 Sep '15

18 Sep '15

I finally got BackupPC working under Centos-7.1 after several hours of pain. I had been running it for several years under CentOS-6, and probably CentOS-5, but there seem to me to have been several new issues that arise with CentOS-7. In my experience, the official documentation on this, <http://backuppc.sourceforge.net/faq/BackupPC.html>, is more or less useless unless you have a very long time to spend. It suffers from the usual Linux disease of having inordinately long explanations of everything with no examples of the actual commands a real person has to give. The explanation in <https://wiki.centos.org/HowTos/BackupPC> (which I only found later) is much better, though it starts with the warning "This page is no longer maintained, having been abandoned on 2009-09-17". I thought I'd write a 1-page note to myself of the steps I took, in preparation for CentOS-8... I have a couple of questions that this raises. 1. Why exactly does backuppc want to ssh to root? Is this just a way of running BackupPC as root? 2. The graphical interface seems to be treated as an extra, but what other way is there of accessing BackupPC? Is there a CLI approach? If so, where is the list of transfer requests kept? -- Timothy Murphy gayleard /at/ eircom.net School of Mathematics, Trinity College, Dublin

6 12

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss