Hi!
On C7 I enabled the debuginfo repo and ran:
debuginfo-install glibc-2.17-55.el7.x86_64 keyutils-libs-1.5.8-3.el7.x86_64 krb5-libs-1.11.3-49.el7.x86_64 libcom_err-1.42.9-4.el7.x86_64 libselinux-2.2.2-6.el7.x86_64 openssl-libs-1.0.1e-34.el7_0.4.x86_64 pcre-8.32-12.el7.x86_64 xz-libs-5.1.2-8alpha.el7.x86_64 zlib-1.2.7-13.el7.x86_64
Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile
* base: mirror.es.its.nyu.edu
* extras: mirror.cs.pitt.edu
* updates: mirrors.lga7.us.voxel.net
--> Running transaction check
---> Package e2fsprogs-debuginfo.x86_64 0:1.42.9-4.el7 will be installed
---> Package gcc-debuginfo.x86_64 0:4.8.2-16.el7 will be installed
--> Processing Dependency: gcc-base-debuginfo = 4.8.2-16.el7 for package: gcc-debuginfo-4.8.2-16.el7.x86_64
---> Package glibc-debuginfo.x86_64 0:2.17-55.el7 will be installed
--> Processing Dependency: glibc-debuginfo-common = 2.17-55.el7 for package: glibc-debuginfo-2.17-55.el7.x86_64
---> Package keyutils-debuginfo.x86_64 0:1.5.8-3.el7 will be installed
---> Package krb5-debuginfo.x86_64 0:1.11.3-49.el7 will be installed
---> Package libselinux-debuginfo.x86_64 0:2.2.2-6.el7 will be installed
---> Package libverto-debuginfo.x86_64 0:0.2.5-4.el7 will be installed
---> Package nss-softokn-debuginfo.x86_64 0:3.15.4-2.el7 will be installed
---> Package openssl-debuginfo.x86_64 1:1.0.1e-34.el7_0.4 will be installed
---> Package pcre-debuginfo.x86_64 0:8.32-12.el7 will be installed
---> Package xz-debuginfo.x86_64 0:5.1.2-8alpha.el7 will be installed
---> Package yum-plugin-auto-update-debug-info.noarch 0:1.1.31-25.el7_0 will be installed
---> Package zlib-debuginfo.x86_64 0:1.2.7-13.el7 will be installed
--> Running transaction check
---> Package gcc-base-debuginfo.x86_64 0:4.8.2-16.el7 will be installed
---> Package glibc-debuginfo-common.x86_64 0:2.17-55.el7 will be installed
--> Finished Dependency Resolution
Dependencies Resolved
====================================================================================================
Package Arch Version Repository Size
====================================================================================================
Installing:
e2fsprogs-debuginfo x86_64 1.42.9-4.el7 debug 1.4 M
gcc-debuginfo x86_64 4.8.2-16.el7 debug 194 M
glibc-debuginfo x86_64 2.17-55.el7 debug 9.2 M
keyutils-debuginfo x86_64 1.5.8-3.el7 debug 84 k
krb5-debuginfo x86_64 1.11.3-49.el7 debug 4.1 M
libselinux-debuginfo x86_64 2.2.2-6.el7 debug 704 k
libverto-debuginfo x86_64 0.2.5-4.el7 debug 53 k
nss-softokn-debuginfo x86_64 3.15.4-2.el7 debug 1.7 M
openssl-debuginfo x86_64 1:1.0.1e-34.el7_0.4 debug 3.7 M
pcre-debuginfo x86_64 8.32-12.el7 debug 1.0 M
xz-debuginfo x86_64 5.1.2-8alpha.el7 debug 528 k
yum-plugin-auto-update-debug-info noarch 1.1.31-25.el7_0 updates 22 k
zlib-debuginfo x86_64 1.2.7-13.el7 debug 243 k
Installing for dependencies:
gcc-base-debuginfo x86_64 4.8.2-16.el7 debug 2.7 M
glibc-debuginfo-common x86_64 2.17-55.el7 debug 8.6 M
Transaction Summary
====================================================================================================
Install 13 Packages (+2 Dependent packages)
Total size: 227 M
Installed size: 1.0 G
Is this ok [y/d/N]: y
Downloading packages:
warning: /var/cache/yum/x86_64/7/debug/packages/gcc-base-debuginfo-4.8.2-16.el7.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID b6792c39: NOKEY
Retrieving key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-Debug-7
GPG key at file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-Debug-7 (0xF4A80EB5) is already installed
Importing GPG key 0xB6792C39:
Userid : "CentOS-7 Debug (CentOS-7 Debuginfo RPMS) <security(a)centos.org>"
Fingerprint: 759d 690f 6099 2d52 6a35 8cbd d0f2 5a3c b679 2c39
Package : centos-release-7-0.1406.el7.centos.2.4.x86_64 (@updates)
From : /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-Debug-7
Is this ok [y/N]: y
Key imported successfully
Import of key(s) didn't help, wrong key(s)?
Public key for gcc-base-debuginfo-4.8.2-16.el7.x86_64.rpm is not installed
Failing package is: gcc-base-debuginfo-4.8.2-16.el7.x86_64
GPG Keys are configured as: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-Debug-7
----------- end of debuginfo-install output -----------------
Note that it was unable to install the GPG key for
gcc-base-debuginfo-4.8.2-16.el7.x86_64.rpm
Anyone got any clues why, or what I do about it? I really need the
debuginfo for, one hopes, solving a problem I'm struggling with.
thanks!
--
---- Fred Smith -- fredex(a)fcshome.stoneham.ma.us -----------------------------
The Lord is like a strong tower.
Those who do what is right can run to him for safety.
--------------------------- Proverbs 18:10 (niv) -----------------------------
Hello,
I just install the newest version of Centos 7 and I am a bit disappointed
with new /etc/rc/local file
I found that it's not usable anymore.
*[root@lab3 ~]# cat /etc/rc.local*
" THIS FILE IS ADDED FOR COMPATIBILITY PURPOSES"
It is highly advisable to create own systemd services or udev rules
to run scripts during boot instead of using this file.
Usually I was added my script to /etc/rc.local
*[root@lab3 ~]# echo /usr/bin/bash /opt/ssh_tunnel.sh >> /etc/rc.local*
And it was working perfect.
What I should do in new Centos 7, please help.
*--*
*Best regards.*
*Alex Berber*
*+9 72 54 285 952 3*
*www.linuxspace.org* <http://www.linuxspace.org/>
Thanks.
I will try to use this solution (Second Way) and I'll report how it works.
This is very critical for me.
On Wed, Aug 20, 2014 at 5:58 PM, Reindl Harald <h.reindl(a)thelounge.net>
wrote:
>
> "Type=oneshot" does what the name says -> fire up a command once
> it expects that this command is short running
> since it is a bash-script and the PID is the one from
> the bash which is supposed to end after it has finished
> it would fail/restart all the time in case of monitoring
>
> "Type=simple" is a long running, non-forking service aka a
> ordinary binary which don't exit and so it's PID can be
> watched and if it disappears without a stop command, well
>
> as said, i have a lot of SSH tunnels expected to work
> 24 hours a day over different networks with Type=simple
>
> http://www.freedesktop.org/software/systemd/man/systemd.service.html
>
> Am 20.08.2014 um 16:40 schrieb Alan Holt:
> > Hello,
> >
> > thank you for your quick answer.
> >
> > You are completely right with this:
> >
> > because they die away in case of network errors and reboots
> >
> >
> > my script contain Reverse SSH Tunnel:
> > [root@lab3 system]# cat /opt/ssh_tunnel.sh
> > #!/bin/bash
> > ssh -f -N -R 12345:localhost:22 root(a)158.216.189.170 <mailto:
> root(a)158.216.189.170>
> >
> > So as I understood from your explanation, I can do it in two different
> ways.
> >
> > *First way: *
> > To create systemd-unit with path to existing script:
> >
> > [Unit]
> > Description=My Service
> > After=network.service systemd-networkd.service network-online.target
> > [Service]
> > Type=oneshot
> > *ExecStart=/usr/bin/bash /opt/ssh_tunnel.sh*
> > [Install]
> > WantedBy=multi-user.target
> >
> >
> >
> > *Second way:*
> > To create systemd-unit with all configuration inside.
> >
> > [Unit]
> > Description=SSH-Forwarding
> > After=network.service systemd-networkd.service network-online.target
> > [Service]
> > Type=simple
> > ExecStart=*/usr/bin/ssh -i /home/gateway/.ssh/id_ecdsa gateway@${REMOTE_HOST}
> -N -C
> > **-L${LOCAL_ADDRESS}:${LOCAL_PORT}:127.0.0.1:${REMOTE_PORT}
> > *Restart=always
> > RestartSec=60
> > TimeoutSec=30
> > CapabilityBoundingSet=CAP_NET_BIND_SERVICE CAP_DAC_OVERRIDE
> > [Install]
> > WantedBy=multi-user.target
> >
> >
> > But in First Way I don't see this records:
> >
> > Restart=always
> > RestartSec=60
> > TimeoutSec=30
> >
> >
> > So that means that my tunnel will die from time to time. (because
> network failure or something like that)
> > And i see difference in this record (I will try to learn about it):
> >
> > Type=oneshot
> > Type=simple
> >
> >
> > So this means that the best practice is to use *Second Way* described by
> you?
> >
> >
> > On Wed, Aug 20, 2014 at 4:24 PM, Reindl Harald <h.reindl(a)thelounge.net
> <mailto:h.reindl@thelounge.net>> wrote:
> >
> >
> > Am 20.08.2014 um 15:07 schrieb Alan Holt:
> > > I just install the newest version of Centos 7 and I am a bit
> disappointed
> > > with new /etc/rc/local file
> > > I found that it's not usable anymore.
> > >
> > > *[root@lab3 ~]# cat /etc/rc.local*
> > > " THIS FILE IS ADDED FOR COMPATIBILITY PURPOSES"
> > > It is highly advisable to create own systemd services or udev rules
> > > to run scripts during boot instead of using this file.
> > >
> > > Usually I was added my script to /etc/rc.local
> > >
> > > *[root@lab3 ~]# echo /usr/bin/bash /opt/ssh_tunnel.sh >>
> /etc/rc.local*
> > >
> > > And it was working perfect.
> > >
> > > What I should do in new Centos 7, please help
> >
> > create a systemd-unit?
> >
> > in general such scripts for port-forwarding are plain crap
> > because they die away in case of network errors and reboots
> >
> > look at the service below, this survives a restart of the
> > forwarded remote machine because in case of a failure after
> > 60 seconds it executes ExecStart again
> >
> > and no - don't put multiple forwards in one service
> >
> > i have a machine with 8 such forwarder-services and they
> > are monitored by systemd because one MAINPID
> >
> _____________________________________________________________________________
> >
> > * touch /etc/systemd/system/tunnel.service
> > * put the content below in the file
> > * systemctl enable tunnel.service
> > * systemctl start tunnel.service
> >
> > [Unit]
> > Description=My Service
> > After=network.service systemd-networkd.service network-online.target
> >
> > [Service]
> > Type=oneshot
> > ExecStart=/usr/bin/bash /opt/ssh_tunnel.sh
> >
> > [Install]
> > WantedBy=multi-user.target
> >
> _____________________________________________________________________________
> >
> > [Unit]
> > Description=SSH-Forwarding
> > After=network.service systemd-networkd.service network-online.target
> >
> > [Service]
> > Type=simple
> > ExecStart=/usr/bin/ssh -i /home/gateway/.ssh/id_ecdsa gateway@${REMOTE_HOST}
> -N -C
> > -L${LOCAL_ADDRESS}:${LOCAL_PORT}:127.0.0.1:${REMOTE_PORT}
> > Restart=always
> > RestartSec=60
> > TimeoutSec=30
> > CapabilityBoundingSet=CAP_NET_BIND_SERVICE CAP_DAC_OVERRIDE
> >
> > [Install]
> > WantedBy=multi-user.target
> >
> _____________________________________________________________________________
> >
> > ${REMOTE_HOST} = the machine with the service you want forwarded
> > ${LOCAL_ADDRESS} = 127.0.0.1 or your WAN-IP if the port should be
> reachable from your LAN
> > ${LOCAL_PORT} = the port on your side
> > ${REMOTE_PORT} = the port of the service you want to forward
> >
> >
> >
> >
> > --
> > /בברכה, /
> > /אלכס ברבר/
> > /+9 72 54 285 952 3
> > /
> > /www.linuxspace.org/ <http://www.linuxspace.org>
> > /--/
> > /Best regards./
> > /Alex Berber/
> > /+9 72 54 285 952 3/
> > /www.linuxspace.org/ <http://www.linuxspace.org/>
>
> --
>
> Reindl Harald
> the lounge interactive design GmbH
> A-1060 Vienna, Hofmühlgasse 17
> CTO / CISO / Software-Development
> m: +43 (676) 40 221 40, p: +43 (1) 595 3999 33
> icq: 154546673, http://www.thelounge.net/
>
> http://www.thelounge.net/signature.asc.what.htm
>
>
--
*בברכה, *
*אלכס ברבר*
*+9 72 54 285 952 3*
*www.linuxspace.org* <http://www.linuxspace.org>
*--*
*Best regards.*
*Alex Berber*
*+9 72 54 285 952 3*
*www.linuxspace.org* <http://www.linuxspace.org/>
Hello,
thank you for your quick answer.
You are completely right with this:
because they die away in case of network errors and reboots
my script contain Reverse SSH Tunnel:
[root@lab3 system]# cat /opt/ssh_tunnel.sh
#!/bin/bash
ssh -f -N -R 12345:localhost:22 root(a)158.216.189.170
So as I understood from your explanation, I can do it in two different ways.
*First way: *
To create systemd-unit with path to existing script:
[Unit]
> Description=My Service
> After=network.service systemd-networkd.service network-online.target
> [Service]
> Type=oneshot
> *ExecStart=/usr/bin/bash /opt/ssh_tunnel.sh*
> [Install]
> WantedBy=multi-user.target
*Second way:*
To create systemd-unit with all configuration inside.
[Unit]
> Description=SSH-Forwarding
> After=network.service systemd-networkd.service network-online.target
> [Service]
> Type=simple
> ExecStart=
> */usr/bin/ssh -i /home/gateway/.ssh/id_ecdsa gateway@${REMOTE_HOST} -N -C*
> *-L${LOCAL_ADDRESS}:${LOCAL_PORT}:127.0.0.1:${REMOTE_PORT}*Restart=always
> RestartSec=60
> TimeoutSec=30
> CapabilityBoundingSet=CAP_NET_BIND_SERVICE CAP_DAC_OVERRIDE
> [Install]
> WantedBy=multi-user.target
But in First Way I don't see this records:
Restart=always
> RestartSec=60
> TimeoutSec=30
So that means that my tunnel will die from time to time. (because network
failure or something like that)
And i see difference in this record (I will try to learn about it):
Type=oneshot
> Type=simple
So this means that the best practice is to use *Second Way* described by
you?
PS: Sry for double sending
On Wed, Aug 20, 2014 at 4:24 PM, Reindl Harald <h.reindl(a)thelounge.net>
wrote:
>
> Am 20.08.2014 um 15:07 schrieb Alan Holt:
> > I just install the newest version of Centos 7 and I am a bit disappointed
> > with new /etc/rc/local file
> > I found that it's not usable anymore.
> >
> > *[root@lab3 ~]# cat /etc/rc.local*
> > " THIS FILE IS ADDED FOR COMPATIBILITY PURPOSES"
> > It is highly advisable to create own systemd services or udev rules
> > to run scripts during boot instead of using this file.
> >
> > Usually I was added my script to /etc/rc.local
> >
> > *[root@lab3 ~]# echo /usr/bin/bash /opt/ssh_tunnel.sh >> /etc/rc.local*
> >
> > And it was working perfect.
> >
> > What I should do in new Centos 7, please help
>
> create a systemd-unit?
>
> in general such scripts for port-forwarding are plain crap
> because they die away in case of network errors and reboots
>
> look at the service below, this survives a restart of the
> forwarded remote machine because in case of a failure after
> 60 seconds it executes ExecStart again
>
> and no - don't put multiple forwards in one service
>
> i have a machine with 8 such forwarder-services and they
> are monitored by systemd because one MAINPID
>
> _____________________________________________________________________________
>
> * touch /etc/systemd/system/tunnel.service
> * put the content below in the file
> * systemctl enable tunnel.service
> * systemctl start tunnel.service
>
> [Unit]
> Description=My Service
> After=network.service systemd-networkd.service network-online.target
>
> [Service]
> Type=oneshot
> ExecStart=/usr/bin/bash /opt/ssh_tunnel.sh
>
> [Install]
> WantedBy=multi-user.target
>
> _____________________________________________________________________________
>
> [Unit]
> Description=SSH-Forwarding
> After=network.service systemd-networkd.service network-online.target
>
> [Service]
> Type=simple
> ExecStart=/usr/bin/ssh -i /home/gateway/.ssh/id_ecdsa gateway@${REMOTE_HOST}
> -N -C
> -L${LOCAL_ADDRESS}:${LOCAL_PORT}:127.0.0.1:${REMOTE_PORT}
> Restart=always
> RestartSec=60
> TimeoutSec=30
> CapabilityBoundingSet=CAP_NET_BIND_SERVICE CAP_DAC_OVERRIDE
>
> [Install]
> WantedBy=multi-user.target
>
> _____________________________________________________________________________
>
> ${REMOTE_HOST} = the machine with the service you want forwarded
> ${LOCAL_ADDRESS} = 127.0.0.1 or your WAN-IP if the port should be
> reachable from your LAN
> ${LOCAL_PORT} = the port on your side
> ${REMOTE_PORT} = the port of the service you want to forward
>
>
--
*בברכה, *
*אלכס ברבר*
*+9 72 54 285 952 3*
*www.linuxspace.org* <http://www.linuxspace.org>
*--*
*Best regards.*
*Alex Berber*
*+9 72 54 285 952 3*
*www.linuxspace.org* <http://www.linuxspace.org/>
Hi,
Is anyone here using a Logitech wireless mouse our keyboard or whatever
using a "unifying receiver". Any luck with pairing new devices with the
unit?
I've tried various different programs from the net that's supposed to be
able to do this, but they all fail in one way or the other.
"pairing_tool" and "ltpair" will exit with a "broken pipe" message,
while PyUnify.py from https://github.com/AveryLouie/BlogDocs fails says
"usb.core.USBError: Input/output error", and solaar (installed via the
EPEL Testing repo) fails in the following manner:
Traceback (most recent call last):
File "/usr/bin/solaar-cli", line 42, in <module>
solaar.cli.main()
File "/usr/lib/python2.6/site-packages/solaar/cli.py", line 429, in main
args = _parse_arguments()
File "/usr/lib/python2.6/site-packages/solaar/cli.py", line 421, in
_parse_arguments
logging.root.addHandler(logging.NullHandler())
AttributeError: 'module' object has no attribute 'NullHandler'
This is on a CentOS 6 x86_64 system with all updates installed.
Any other ideas?
In case you don't know how these units work, note that they generally
work just like that as long as you use the device and receiver from the
same box, so as to speak. The problem is linking a device to a different
receiver - which is supported, but requires software.
- Toralf||||||
This e-mail, including any attachments and response string, may contain proprietary information which is confidential and may be legally privileged. It is for the intended recipient only. If you are not the intended recipient or transmission error has misdirected this e-mail, please notify the author by return e-mail and delete this message and any attachment immediately. If you are not the intended recipient you must not use, disclose, distribute, forward, copy, print or rely on this e-mail in any way except as permitted by the author.
Hi Dan -
"ausearch -m avc -ts recent" produces no output. If I run it as "ausearch -f
virsh" then it produces output similar to this. Each day's run of logwatch
produces three of these audit log entries. The a1 and a2 values are different
for each entry, but everything else is the same.
===============
time->Mon Aug 18 03:21:03 2014
type=SYSCALL msg=audit(1408350063.257:7492): arch=c000003e syscall=21
success=no exit=-13 a0=11ee230 a1=4 a2=7fff722837b0 a3=7fff72283640 items=0
ppid=2815 pid=2816 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=(none) ses=981 comm="bash" exe="/usr/bin/bash"
subj=system_u:system_r:logwatch_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1408350063.257:7492): avc: denied { read } for pid=2816
comm="bash" name="virsh" dev="dm-0" ino=135911290
scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023
tcontext=system_u:object_r:virsh_exec_t:s0 tclass=file
===============
I thought about using audit2allow as you suggest. The problem is then I don't
really know what change is required. What exactly will it do? And is there a
guarantee that it will work?
Regarding your general question ... It seems to me that logwatch can be used
to provide feedback on operational status of almost anything on the system.
If you go beyond the typical reading of log files, then that often requires
running some script or utility program or something. Anytime that is done, I
think this kind of problem will appear.
Much of what logwatch does is running files through "cat". That process runs
as "bin_t" which must be a general type. I wonder what would happen if I
changed virsh to the same type.
For what it is worth, I have another computer running CentOS 6.5 and
VirtualBox. The VBoxManage program must run as the same user which is running
the virtual machines, which frustrates me to no end. I finally figured out a
way to work around it by setting up a user cron job under that user. It saves
the output to a text file. The logwatch script then comes along and reads that
file into its output. It works, but it is not ideal. There are obvious
problems with synchronization, plus if a computer is running VMs under
multiple user accounts, then multiple user cron jobs are needed.
Thanks - Bill Gee
=============================
> _______________________________________________
> CentOS mailing list
> CentOS(a)centos.org
> http://lists.centos.org/mailman/listinfo/centos
What AVC messages are you seeing?
ausearch -m avc -ts recent.
I would put the machine in permissive mode, run your tests and then add
the allow rules using
audit2allow -M mylogwatch
Message: 8
Date: Fri, 15 Aug 2014 11:22:40 -0400
From: Daniel J Walsh <dwalsh(a)redhat.com>
Subject: Re: [CentOS] SELinux vs. logwatch and virsh
To: CentOS mailing list <centos(a)centos.org>
Message-ID: <53EE25C0.3040404(a)redhat.com>
Content-Type: text/plain; charset=windows-1252
On 08/14/2014 11:02 AM, Bill Gee wrote:
> Hello everyone -
>
> I am stumped ... Does anyone have suggestions on how to proceed? Is there
a way
> to get what I want?
>
> The environment: CentOS 7.0 with latest patches.
>
> The goal: I want logwatch to include a report on the status of kvm virtual
computers.
>
> The problem: When run from anacron, SELinux denies permission for the virsh
utility.
> Here is a portion of the logwatch output:
>
> --------------------- KVM libvirt status report Begin
------------------------
>
> Date Range: yesterday
> /etc/logwatch/scripts/services/libvirt: line 15: /usr/bin/virsh: Permission
denied
>
> ---------------------- KVM libvirt status report End
-------------------------
>
> If I "run-parts /etc/cron.daily" from a root console, it all works. Same
if I run "logwatch"
> from a root console.
>
> I set SELinux to permissive and that allows virsh to run. Therefore I know
it is
> something to do with SELinux.
>
> The logwatch script is:
>
> #Lots of comments
> /usr/bin/virsh list --all
>
> I see the selinux security context of virsh is
>
> system_u:object_r:virsh_exec_t:s0
>
> while logwatch.pl runs as
>
> system_u:object_r:logwatch_exec_t:s0
>
> As I understand it, selinux does not permit having multiple type settings
for a file. Any
> file can have exactly one type setting.
>
> I ran this command hoping it would add another type to the virsh program.
>
> semanage fcontext -a -t logwatch_exec_t /usr/bin/virsh
>
> semanage fcontext --list /usr/bin/virsh | grep virsh
> /usr/bin/virsh all files
> system_u:object_r:logwatch_exec_t:s0
> /usr/bin/virsh regular file
system_u:object_r:virsh_exec_t:s0
> /usr/sbin/xl regular file
system_u:object_r:virsh_exec_t:s0
> /usr/sbin/xm regular file
system_u:object_r:virsh_exec_t:s0
>
> Semanage did add the new type, but that did not fix the problem. Virsh still
gets
> "permission denied" when logwatch tries to run it.
>
> Thanks - Bill Gee
> _______________________________________________
> CentOS mailing list
> CentOS(a)centos.org
> http://lists.centos.org/mailman/listinfo/centos
BTW if you think this is something we should do in general in such a way
as logwatch can only look at the content in Read Only mode, then we
might want it to become default.
------------------------------
hi!
I got a problem with one of my servers where the boot process fails,
because it cannot find its root partition.
My /boot/grub/grub.conf uses to look like
---8<---
title CentOS (2.6.32-431.17.1.el6.x86_64)
root (hd0,0)
kernel /vmlinuz-2.6.32-431.17.1.el6.x86_64 ro root=UUID=8ef1f6cb-5dfc-497e-83d0-8d91cbbe4939 rd_NO_LUKS LANG=en_US.UTF-8 rd_NO_MD quiet SYSFONT=latarcyrheb-sun16 rhgb crashkernel=auto rd_NO_DM rd_NO_LVM KEYBOARDTYPE=pc KEYTABLE=de
initrd /initramfs-2.6.32-431.17.1.el6.x86_64.img
---8<--
I could get the system to boot again by just replacing the
"root=UUID-..." part with "root=/dev/sdb3"
when I started looking around, I noticed that the "/dev/disk"by-uuid"
directory was not there. The "by-id" as well as the "by-path"
directories were both there. I tried to create directory and the links
in the directory manually, but they were gone after the next reboot.
I assume that these /dev/disk/ entries are created by some process at
boot time, but I have no clue how this is done nor what is wrong with
my system.
I checked what blkid -L says, but this seems to be OK.
---8<---
device fs_type label mount point UUID
-----------------------------------------------------------------------------------------
/dev/sda1 ext4 /mnt/raid a574f30b-fa43-4e34-8498-1cb29c4c261f
/dev/sdb1 ext4 /boot 01746f38-6289-4b03-8011-bfac89ed89bd
/dev/sdb2 swap <swap> 903a51b7-393d-4df9-9b58-f06a0a80a748
/dev/sdb3 ext4 / 8ef1f6cb-5dfc-497e-83d0-8d91cbbe4939
---8<---
Any help?
btw., the problem appeared when I installed a 18TB raid array. I had
to compile the e2fsprogs from the most recent sources using this
recipe
http://blog.ronnyegner-consulting.de/2011/08/18/ext4-and-the-16-tb-limit-no…
to install a very large ext4 file system on the raid disk.
best regards
---
Michael Schumacher
PAMAS Partikelmess- und Analysesysteme GmbH
Dieselstr.10, D-71277 Rutesheim
Tel +49-7152-99630
Fax +49-7152-996333
Geschäftsführer: Gerhard Schreck
Handelsregister B Stuttgart HRB 252024
Things like this keep showing up in my my logs. Any idea what to look
for to (1) figure out why and (2) track it to a particular service?
systemd: Failed to mark scope session-19.scope as abandoned : Stale file
handle
--
-- Steve
On Mon, August 18, 2014 09:05, Valeri Galtsev wrote:
>
> On Mon, August 18, 2014 5:50 am, Toralf Lund wrote:
>
>>
>> This e-mail, including any attachments and response string, may contain
>> proprietary information which is confidential and may be legally
>> privileged. It is for the intended recipient only. If you are not the
>> intended recipient or transmission error has misdirected this e-mail,
>> please notify the author by return e-mail and delete this message and any
>> attachment immediately. If you are not the intended recipient you must not
>> use, disclose, distribute, forward, copy, print or rely on this e-mail in
>> any way except as permitted by the author.
>
> I'm sorry if that offends anyone, the the BS nature of e-mail footers like
> this one always offends my intelligence. As a recipient of e-mail I didn't
> give my consent to be obliged to anything. whatever you sent me was at
> your sole discretion. You want any obligations from the recipient of your
> message, you should contact the recipient first and get him agree to be
> obliged to anything you request.
>
> Who is the idiot lawyer who wrote it? He shouldn't even have layer degree
> for incompetence! Even I, not lawyer, do understand that you can not make
> the person obliged to do or not do anything by unilaterally doing
> something (sending that person e-mail with idiotic footer).
>
You mean like forcing someone to agree to the terms of a license through the
act opening the package that contains the text of said license? You would be
amazed as what corporate interests have twisted the courts into doing for them
through sponsored legislation (DMCA for example).
I agree about the BS part but that does not make it unenforceable BS in some
jurisdictions. And then there is always the threat of impoverishment through
litigation. A big enough complainant can simply litigate frivolous torts to
impose an economic penalty on its victim regardless of the outcome. Those
sorts of disclaimers simple provide a pretext.
I just delete messages with such things; unread whenever I notice them in
time, otherwise ignoring the contents if I do not.
--
*** E-Mail is NOT a SECURE channel ***
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
I'm running firefox on Centos 6 and am trying to watch a movie on hulu.
Hulu requires Flash Player 10.1.53.64 or higher
What to do?
My recollection is that dealing with flash has always been a pain
and that it recently got worse when Adobe EOLed flash for linux.
Is this correct?
[hennebry@localhost grease]$ uname -a
Linux localhost.localdomain 2.6.32-431.20.3.el6.x86_64 #1 SMP Thu Jun 19
21:14:45 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
[hennebry@localhost grease]$
A pointer to instructions would be good.
--
Michael hennebry(a)web.cs.ndsu.NoDak.edu
"SCSI is NOT magic. There are *fundamental technical
reasons* why it is necessary to sacrifice a young
goat to your SCSI chain now and then." -- John Woods