Discuss

discuss@lists.centos.org

34758 discussions

Re: [CentOS] Trying to override MAC addr
by Robert Moskowitz 21 Aug '14

21 Aug '14

On 08/21/2014 10:15 AM, Reindl Harald wrote: > > Am 21.08.2014 um 16:09 schrieb Robert Moskowitz: >> I am trying to override the mac addr. Now this is on an armv7 actually >> running the F19 kernel and Redsleeve 6, but it SHOULD be standard >> Centos6 ifcfg-eth0 content. Of course RSEL does not start with a >> ifcfg-eth0 file, letting network services do all the work, so I am >> starting from scratch, using the file from one of my C6 boxes with >> static addressing. My file has in it: >> >> DEVICE="eth0" >> BOOTPROTO=none >> NM_CONTROLLED="no" >> ONBOOT="yes" >> TYPE="Ethernet" >> NAME="System eth0" >> DNS1=208.83.67.188 >> GATEWAY="208.83.67.177" >> IPADDR="208.83.67.179" >> HOSTNAME="rigel2.htt-consult.com" >> IPV6INIT="yes" >> MACADDR=02:67:15:00:01:79 >> MTU=1500 > that's easy - you need to tell it the physical too > works from Fedora 10 up to Fedora 20 that way > > [root@srv-rhsoft:~]$ cat ifcfg-eth1 > DEVICE=eth1 > HWADDR=68:05:ca:0d:62:c1 > MACADDR=00:50:8d:b5:cc:de > > "00:50:8d:b5:cc:de" is the on my interface has after it is up > "68:05:ca:0d:62:c1" is the pysical one of the device before fake it OK. I ws going by: http://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-networkscripts-… which says: MACADDR=/<MAC-address>/ where /<MAC-address>/ is the hardware address of the Ethernet device in the form /AA:BB:CC:DD:EE:FF/. This directive is used to assign a MAC address to an interface, overriding the one assigned to the physical NIC. This directive should *not* be used in conjunction with HWADDR. > > [root@srv-rhsoft:~]$ ifconfig eth1 > eth1: flags=67<UP,BROADCAST,RUNNING> mtu 1500 > inet 62.178.103.85 netmask 255.255.255.0 broadcast 255.255.255.255 > ether 00:50:8d:b5:cc:de txqueuelen 500 (Ethernet) > RX packets 74959980 bytes 25037014848 (23.3 GiB) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 67607627 bytes 39867204808 (37.1 GiB) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > device interrupt 16 memory 0xf7cc0000-f7ce0000 >

1 0

CentOS-announce Digest, Vol 114, Issue 11
by centos-announce-request＠centos.org 21 Aug '14

21 Aug '14

Send CentOS-announce mailing list submissions to centos-announce(a)centos.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.centos.org/mailman/listinfo/centos-announce or, via email, send a message with subject or body 'help' to centos-announce-request(a)centos.org You can reach the person managing the list at centos-announce-owner(a)centos.org When replying, please edit your Subject line so it is more specific than "Re: Contents of CentOS-announce digest..." Today's Topics: 1. CESA-2014:1075 Moderate CentOS 6 qemu-kvm Update (Johnny Hughes) 2. CEBA-2014:1080 CentOS 6 ccid Update (Johnny Hughes) 3. CEBA-2014:1081 CentOS 7 perl-Test-Pod FASTTRACK BugFix Update (Johnny Hughes) ---------------------------------------------------------------------- Message: 1 Date: Tue, 19 Aug 2014 10:00:56 +0000 From: Johnny Hughes <johnny(a)centos.org> Subject: [CentOS-announce] CESA-2014:1075 Moderate CentOS 6 qemu-kvm Update To: centos-announce(a)centos.org Message-ID: <20140819100056.GA27838(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Security Advisory 2014:1075 Moderate Upstream details at : https://rhn.redhat.com/errata/RHSA-2014-1075.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 4c2f64fbfa724282ccea4c96a54bf8efd0ef9b0994c590b10208f49192f926ae qemu-guest-agent-0.12.1.2-2.415.el6_5.14.i686.rpm x86_64: 6ece8abdbb5f15c1a4fda968db4a9f2a35d3b273c66d3f9e3777796259762d15 qemu-guest-agent-0.12.1.2-2.415.el6_5.14.x86_64.rpm 5754d91f336abb86787e1cc3378477de5407c1a3a3c7e20a9a40783a78e8afee qemu-img-0.12.1.2-2.415.el6_5.14.x86_64.rpm 4ce7d58ddf89b67cbcaeda217aba78b8a3b4facf1ed632c0ee90ac4f27d00a86 qemu-kvm-0.12.1.2-2.415.el6_5.14.x86_64.rpm 4c10810d91f41199b63fdf5913a6090c7bc1b1ebda300b63c5b934dc9773f5bc qemu-kvm-tools-0.12.1.2-2.415.el6_5.14.x86_64.rpm Source: d1c7b724bfb2a1c3ea74e835f2b893ce70eeef66bc95ff073732fbe0efb615d5 qemu-kvm-0.12.1.2-2.415.el6_5.14.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ Message: 2 Date: Wed, 20 Aug 2014 13:00:22 +0000 From: Johnny Hughes <johnny(a)centos.org> Subject: [CentOS-announce] CEBA-2014:1080 CentOS 6 ccid Update To: centos-announce(a)centos.org Message-ID: <20140820130022.GA5091(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Bugfix Advisory 2014:1080 Upstream details at : https://rhn.redhat.com/errata/RHBA-2014-1080.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 2ac61bf52b8fead7aa134984cfe47dabef0e038e94bfef1141879a2f7224390c ccid-1.3.9-6.1.el6_5.i686.rpm x86_64: 3acf42c67fbe2f9cd561818b03e7a4d7b1eb7727f67ca31e0d1409bee059e7e5 ccid-1.3.9-6.1.el6_5.x86_64.rpm Source: 2c1128b52d06abb7ad4c12e490460fc22fc40a7fdaa24dc07ad940f934bb13f6 ccid-1.3.9-6.1.el6_5.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ Message: 3 Date: Wed, 20 Aug 2014 13:11:14 +0000 From: Johnny Hughes <johnny(a)centos.org> Subject: [CentOS-announce] CEBA-2014:1081 CentOS 7 perl-Test-Pod FASTTRACK BugFix Update To: centos-announce(a)centos.org Message-ID: <20140820131114.GA24354(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Bugfix Advisory 2014:1081 Upstream details at : https://rhn.redhat.com/errata/RHBA-2014-1081.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: c81d42c09fc4cfff0342f5ae9e76d7ba7b26377c00ac038f17317f3743094bbb perl-Test-Pod-1.48-3.el7.noarch.rpm Source: da0fb9277a920e37ac3f0b3b1d372093608781ee0a371864ba243efe218feddb perl-Test-Pod-1.48-3.el7.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ _______________________________________________ CentOS-announce mailing list CentOS-announce(a)centos.org http://lists.centos.org/mailman/listinfo/centos-announce End of CentOS-announce Digest, Vol 114, Issue 11 ************************************************

1 0

Re: [CentOS] Skype on CentOS 6.5 (SOLVED)
by Mark LaPierre 21 Aug '14

21 Aug '14

On 08/18/14 22:05, Jim Perrin wrote:> > > On 08/18/2014 08:09 PM, Mark LaPierre wrote: >> Hey Y'all, >> >> About a week ago my Skype installation stopped working. I can start it up >> but I can't log on. Does this have something to do with the recent update >> to LibC? Is there a repo som where that has the latest version of Skype >> for CentOS 6.5? > > No. This is because Microsoft dropped support for older versions of Skype. > > > >> When I go to the Skype web site I see that there is a version several >> versions newer available for RPM based Linux but that one won't even start. >> >> Can anyone offer some sound advice to getting my Skype running again? > > Did you try the directions on the wiki? > > http://wiki.centos.org/HowTos/Skype > > I already had the nuxrepo set up on my system. All that was needed was yum --enablerepo=nuxrepo install skype Thanks for clearing the cobwebs. -- _ °v° /(_)\ ^ ^ Mark LaPierre Registered Linux user No #267004 https://linuxcounter.net/ ****

1 0

yumex for C7
by Robert G. (Doc) Savage 21 Aug '14

21 Aug '14

Can anyone tell me when the udisks, python-pexpect, and pyxdg packages in EPEL will be updated so I can install yumex under CentOS 7? Resolving Dependencies --> Running transaction check ---> Package yumex.noarch 0:3.0.15-1.el7 will be installed --> Processing Dependency: udisks for package: yumex-3.0.15-1.el7.noarch --> Processing Dependency: pyxdg for package: yumex-3.0.15-1.el7.noarch --> Processing Dependency: python-pexpect for package: yumex-3.0.15-1.el7.noarch --> Finished Dependency Resolution Error: Package: yumex-3.0.15-1.el7.noarch (epel) Requires: udisks Error: Package: yumex-3.0.15-1.el7.noarch (epel) Requires: python-pexpect Error: Package: yumex-3.0.15-1.el7.noarch (epel) Requires: pyxdg You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest --Doc Savage Fairview Heights, IL

2 2

lvm module missing in initramfs
by Vlado Potisk 20 Aug '14

20 Aug '14

After upgrading the kernel package, my Centos 7 server didn't boot. Here is a small summary: old kernel = kernel-3.10.0-123.4.4.el7.x86_64 (everything just fine) new kernel = kernel-3.10.0-123.6.3.el7.x86_64 root partition is on a primary partition, NOT on a LVM volume /var partition is on a LVM volume new kernel's boot problem = systemd cannot mount /var partition saying requirements failed or something like that I have find out that the new kernel's initramfs image does not contain the lvm module while the old kernel's initramfs did. I have created a new initramfs with lvm using dracut and could boot the server successfully. However I do not consider this as a fix, and don't know how to find the primary cause of the problem. I need some help finding out who's to blame: Is the lvm module really missing? AFAIK the initramfs exists for one purpose only and that is to mount the root partition. All kernel modules are on this partition and once it is mounted, the kernel can access all hardware it supports - LVM included, of course. The fact is the root partition WAS mounted successfully before the boot process failed and the lvm module is NOT needed for this task. Initramfs did its job fine, didn't it? If that's true and the lvm module is NOT missing in the initramfs, is the boot problem systemd related? Has it failed to activate the LVM? Why? Any help would be appreciated.

1 0

debuginfo
by Fred Smith 20 Aug '14

20 Aug '14

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) -----------------------------

2 2

Run script at startup
by Alan Holt 20 Aug '14

20 Aug '14

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/>

6 6

Re: [CentOS] cleaner than before RHEL7 -> Re: Run script at startup
by Alan Holt 20 Aug '14

20 Aug '14

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/>

1 0

Re: [CentOS] cleaner than before RHEL7 -> Re: Run script at startup
by Alan Holt 20 Aug '14

20 Aug '14

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/>

1 0

Logitech unifying receiver (pairing)
by Toralf Lund 20 Aug '14

20 Aug '14

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.

4 6

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