- openSUSE High Availability

[opensuse-ha] iscsitarget/targetcli - always getting a [::0]:3260 portal although I specified 0.0.0.0:3260
by Per Jessen 28 Mar '18

28 Mar '18

when using the iSCSITarget RA, I always seem to get a target portal of [::0]:3260. If I manually remove and add with targetcli, it works fine - with the RA, the syslog says I got the right thing, but ... With iSCSITarget: (from /var/log/messages) iSCSITarget(t31)[27728]: INFO: Parameter auto_add_default_portal is now 'false'. iSCSITarget(t31)[27767]: INFO: Created target iqn.2018-01.net.hostsuisse:server000816. Created TPG 1. iSCSITarget(t31)[27779]: INFO: Using default IP port 3260 Binding to INADDR_ANY (0.0.0.0) Created network portal 0.0.0.0:3260. Sounds good, but: # targetcli ls o- / ..................................................................................................... [...] o- backstores .......................................................................................... [...] | o- block .............................................................................. [Storage Objects: 1] | | o- z32 .............................................. [/dev/Grp1/numberone (10.0GiB) write-thru activated] | o- fileio ............................................................................. [Storage Objects: 0] | o- pscsi .............................................................................. [Storage Objects: 0] | o- ramdisk ............................................................................ [Storage Objects: 0] o- iscsi ........................................................................................ [Targets: 1] | o- iqn.2018-01.net.hostsuisse:server000816 ....................................................... [TPGs: 1] | o- tpg1 .............................................................................. [gen-acls, no-auth] | o- acls ...................................................................................... [ACLs: 0] | o- luns ...................................................................................... [LUNs: 1] | | o- lun1 ............................................................ [block/z32 (/dev/Grp1/numberone)] | o- portals ................................................................................ [Portals: 1] | o- [::0]:3260 ................................................................................... [OK] I really don't see anything in the RA script that would cause this. Can anyone suggest where to look? -- Per Jessen, Zürich (9.8°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse-ha+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-ha+owner(a)opensuse.org

1 0

[opensuse-ha] ERROR: This Target already exists in configFS
by Per Jessen 28 Mar '18

28 Mar '18

I'm trying to build a storage cluster, to begin with a test setup. I'm using leap423, targetcli, Hawk, I have a drbd device with LVM on top. When I try to start iSCSITarget: 2018-03-27T18:03:59+02:00 office31 iSCSITarget(t31)[15134]: INFO: Parameter auto_add_default_portal is now 'false'. 2018-03-27T18:04:00+02:00 office31 iSCSITarget(t31)[15145]: INFO: Created target iqn.2018-01.net.hostsuisse:server000816. Created TPG 1. 2018-03-27T18:04:00+02:00 office31 iSCSITarget(t31)[15156]: ERROR: This Target already exists in configFS 2018-03-27T18:04:02+02:00 office31 iSCSITarget(t31)[15223]: INFO: Deleted Target iqn.2018-01.net.hostsuisse:server000816. The error is from rtslib, but it looks like the target creation is being attempted twice?? t31 is a member of a group 'klop99' which contains: lvm start iscsitarget iscsilogicalunit I believe the problem is in: /usr/lib/ocf/resource.d/heartbeat/iSCSITarget Patch attached. -- Per Jessen, Zürich (7.2°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland.

2 2

[opensuse-ha] [announce] DRBD 9.0 on opensuse
by Goldwyn Rodrigues 23 Feb '15

23 Feb '15

Hi, DRBD 9.0 (rc1) is available for Opensuse family at the standard opensuse development project on OBS (Opensuse Build Service): https://build.opensuse.org/project/show/network:ha-clustering:Factory The links directly to the repos are: Opensuse 13.2 http://download.opensuse.org/repositories/network:/ha-clustering:/Factory/o… Opensuse Factory http://download.opensuse.org/repositories/network:/ha-clustering:/Factory/o… Opensuse Tumbleweed http://download.opensuse.org/repositories/network:/ha-clustering:/Factory/o… Whats new in DRBD 9.0: * Multiple node replication across a mesh network of up to 32 nodes * Mixed protocols across all nodes: Synchronous and asynchronous * Distributed configuration across the whole cluster with 'drbdmanage' * Auto-Promote of selected nodes * Re-Balancing of volumes across the cluster * Diskless node operation * RDMA integration (e.g. for Infiniband, RoCE, IWarp) * Cinder driver for OpenStack (Upstream for Kilo release) * Nova bits for OpenStack available, will be pushed upstream L-Release -- Goldwyn -- To unsubscribe, e-mail: opensuse-ha+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-ha+owner(a)opensuse.org

2 1

[opensuse-ha] Error removing ldirectord package on CentOS 7
by David Ruiz Estefania 28 Nov '14

28 Nov '14

Hi. Doing some more tests i've found that when I try to remove the ldirectord package on CentOS 7 I get the following error: > error: %preun(ldirectord-3.9.5-4.1.x86_64): macro de ejecución de guión fallido, estado de terminación 1 > Error in PREUN scriptlet in rpm package ldirectord-3.9.5-4.1.x86_64 > Aviso: scriptlet o algún otro tipo de error no fatal ha ocurrido durante la transacción. I've listed the package scriptlets: > [druiz.ext@galeno ~]$ rpm -q --scripts ldirectord > postinstall scriptlet (using /bin/sh): > /sbin/chkconfig --add ldirectord > preuninstall scriptlet (using /bin/sh): > /sbin/chkconfig --del ldirectord > postuninstall program: /sbin/ldconfig As you can see, the package is still using the init.d scripts for uninstalling the service, but on CentOS7 the service it's installed as a Systemd service, so the preuninstall scriptlet exits with error, and the package can't be uninstalled. To do a successful package erase it's mandatory to use the '--setopt=tsflags=noscripts' flag when executing yum, so that it ignores the preuninstall scriptlet. It'll be great to update the install/uninstall scriptlets in ldirectord package, probably just erasing them it's the correct solution, as the Systemd service has been correctly installed/removed from the system without manual configuration after installing/removing the package. Thanks in advanced. David Ruiz Estefanía Administrador de Sistemas Centro de Alta Disponibilidad Correo: cad.ext(a)riojasalud.es Teléfono: +34 941 298 000 - Ext. 84743 Móvil: +34 669 432 808 ________________________________ GOBIERNO DE LA RIOJA AVISO LEGAL: La información contenida en este mensaje es confidencial y está destinada a ser leída sólo por la persona a la que va dirigida. Si Ud. no es el destinatario señalado le informamos que está prohibida, y puede ser ilegal, cualquier divulgación o reproducción de este mensaje. Antes de imprimir este e-mail piense bien si es necesario hacerlo. -- To unsubscribe, e-mail: opensuse-ha+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-ha+owner(a)opensuse.org

2 1

[opensuse-ha] Package ldirectord requires Perl-Net_SSLeay when installing on CentOS 7
by David Ruiz Estefania 26 Nov '14

26 Nov '14

Hi. We're updating our cluster systems from CentOS 6 to CentOs7, using de HA-Clustering repository as software source. But when we try to install ldirectord package on the new CentOS 7 system, it requires the "Perl-Net_SSLeay" package, which is correct for SuSE systems, but on RedHat systems the correct package name it's "Perl-Net-SSLeay", so installing fails on this dependency. Here is some console output with the error: >>> [root@galeno ~]# yum install ldirectord >>> Complementos cargados:fastestmirror, langpacks >>> Loading mirror speeds from cached hostfile >>> * base: ftp.uma.es >>> * epel: fedora.ip-connect.vn.ua >>> * extras: ftp.uma.es >>> * updates: ftp.cixug.es >>> Resolviendo dependencias >>> --> Ejecutando prueba de transacción >>> ---> Paquete ldirectord.x86_64 0:3.9.5-3.3 debe ser instalado >>> --> Procesando dependencias: ipvsadm para el paquete: ldirectord-3.9.5-3.3.x86_64 >>> --> Procesando dependencias: perl(Mail::Send) para el paquete: ldirectord-3.9.5-3.3.x86_64 >>> --> Procesando dependencias: perl(LWP::UserAgent) para el paquete: ldirectord-3.9.5-3.3.x86_64 >>> --> Procesando dependencias: perl(IO::Socket::INET6) para el paquete: ldirectord-3.9.5-3.3.x86_64 >>> --> Procesando dependencias: perl-libwww-perl para el paquete: ldirectord-3.9.5-3.3.x86_64 >>> --> Procesando dependencias: perl-MailTools para el paquete: ldirectord-3.9.5-3.3.x86_64 >>> --> Procesando dependencias: perl(LWP::Debug) para el paquete: ldirectord-3.9.5-3.3.x86_64 >>> --> Procesando dependencias: perl-Net_SSLeay para el paquete: ldirectord-3.9.5-3.3.x86_64 >>> --> Procesando dependencias: perl(Sys::Syslog) para el paquete: ldirectord-3.9.5-3.3.x86_64 >>> --> Ejecutando prueba de transacción >>> ---> Paquete ipvsadm.x86_64 0:1.27-4.el7 debe ser instalado >>> ---> Paquete ldirectord.x86_64 0:3.9.5-3.3 debe ser instalado >>> --> Procesando dependencias: perl-Net_SSLeay para el paquete: ldirectord-3.9.5-3.3.x86_64 >>> ---> Paquete perl-IO-Socket-INET6.noarch 0:2.69-5.el7 debe ser instalado >>> ---> Paquete perl-MailTools.noarch 0:2.12-2.el7 debe ser instalado >>> --> Procesando dependencias: perl(Net::SMTP::SSL) para el paquete: perl-MailTools-2.12-2.el7.noarch >>> ---> Paquete perl-Sys-Syslog.x86_64 0:0.33-3.el7 debe ser instalado >>> ---> Paquete perl-libwww-perl.noarch 0:6.05-2.el7 debe ser instalado >>> --> Procesando dependencias: perl(WWW::RobotRules) >= 6 para el paquete: perl-libwww-perl-6.05-2.el7.noarch >>> --> Procesando dependencias: perl(URI) >= 1.10 para el paquete: perl-libwww-perl-6.05-2.el7.noarch >>> --> Procesando dependencias: perl(Net::HTTP) >= 6.04 para el paquete: perl-libwww-perl-6.05-2.el7.noarch >>> --> Procesando dependencias: perl(LWP::MediaTypes) >= 6 para el paquete: perl-libwww-perl-6.05-2.el7.noarch >>> --> Procesando dependencias: perl(HTTP::Status) >= 6 para el paquete: perl-libwww-perl-6.05-2.el7.noarch >>> --> Procesando dependencias: perl(HTTP::Response) >= 6 para el paquete: perl-libwww-perl-6.05-2.el7.noarch >>> --> Procesando dependencias: perl(HTTP::Request::Common) >= 6 para el paquete: perl-libwww-perl-6.05-2.el7.noarch >>> --> Procesando dependencias: perl(HTTP::Request) >= 6 para el paquete: perl-libwww-perl-6.05-2.el7.noarch >>> --> Procesando dependencias: perl(HTTP::Negotiate) >= 6 para el paquete: perl-libwww-perl-6.05-2.el7.noarch >>> --> Procesando dependencias: perl(HTTP::Date) >= 6 para el paquete: perl-libwww-perl-6.05-2.el7.noarch >>> --> Procesando dependencias: perl(HTTP::Daemon) >= 6 para el paquete: perl-libwww-perl-6.05-2.el7.noarch >>> --> Procesando dependencias: perl(HTTP::Cookies) >= 6 para el paquete: perl-libwww-perl-6.05-2.el7.noarch >>> --> Procesando dependencias: perl(File::Listing) >= 6 para el paquete: perl-libwww-perl-6.05-2.el7.noarch >>> --> Procesando dependencias: perl(URI::Heuristic) para el paquete: perl-libwww-perl-6.05-2.el7.noarch >>> --> Procesando dependencias: perl(URI::Escape) para el paquete: perl-libwww-perl-6.05-2.el7.noarch >>> --> Procesando dependencias: perl(HTML::HeadParser) para el paquete: perl-libwww-perl-6.05-2.el7.noarch >>> --> Procesando dependencias: perl(HTML::Entities) para el paquete: perl-libwww-perl-6.05-2.el7.noarch >>> --> Procesando dependencias: perl(Encode::Locale) para el paquete: perl-libwww-perl-6.05-2.el7.noarch >>> --> Ejecutando prueba de transacción >>> ---> Paquete ldirectord.x86_64 0:3.9.5-3.3 debe ser instalado >>> --> Procesando dependencias: perl-Net_SSLeay para el paquete: ldirectord-3.9.5-3.3.x86_64 >>> ---> Paquete perl-Encode-Locale.noarch 0:1.03-5.el7 debe ser instalado >>> ---> Paquete perl-File-Listing.noarch 0:6.04-7.el7 debe ser instalado >>> ---> Paquete perl-HTML-Parser.x86_64 0:3.71-4.el7 debe ser instalado >>> --> Procesando dependencias: perl(HTML::Tagset) >= 3 para el paquete: perl-HTML-Parser-3.71-4.el7.x86_64 >>> ---> Paquete perl-HTTP-Cookies.noarch 0:6.01-5.el7 debe ser instalado >>> ---> Paquete perl-HTTP-Daemon.noarch 0:6.01-5.el7 debe ser instalado >>> ---> Paquete perl-HTTP-Date.noarch 0:6.02-8.el7 debe ser instalado >>> ---> Paquete perl-HTTP-Message.noarch 0:6.06-6.el7 debe ser instalado >>> --> Procesando dependencias: perl(IO::Uncompress::Bunzip2) >= 2.021 para el paquete: perl-HTTP-Message-6.06-6.el7.noarch >>> --> Procesando dependencias: perl(IO::Compress::Bzip2) >= 2.021 para el paquete: perl-HTTP-Message-6.06-6.el7.noarch >>> --> Procesando dependencias: perl(IO::Uncompress::RawInflate) para el paquete: perl-HTTP-Message-6.06-6.el7.noarch >>> --> Procesando dependencias: perl(IO::Uncompress::Inflate) para el paquete: perl-HTTP-Message-6.06-6.el7.noarch >>> --> Procesando dependencias: perl(IO::Uncompress::Gunzip) para el paquete: perl-HTTP-Message-6.06-6.el7.noarch >>> --> Procesando dependencias: perl(IO::HTML) para el paquete: perl-HTTP-Message-6.06-6.el7.noarch >>> --> Procesando dependencias: perl(IO::Compress::Gzip) para el paquete: perl-HTTP-Message-6.06-6.el7.noarch >>> --> Procesando dependencias: perl(IO::Compress::Deflate) para el paquete: perl-HTTP-Message-6.06-6.el7.noarch >>> --> Procesando dependencias: perl(Compress::Raw::Zlib) para el paquete: perl-HTTP-Message-6.06-6.el7.noarch >>> ---> Paquete perl-HTTP-Negotiate.noarch 0:6.01-5.el7 debe ser instalado >>> ---> Paquete perl-LWP-MediaTypes.noarch 0:6.02-2.el7 debe ser instalado >>> ---> Paquete perl-Net-HTTP.noarch 0:6.06-2.el7 debe ser instalado >>> --> Procesando dependencias: perl(IO::Socket::SSL) >= 1.38 para el paquete: perl-Net-HTTP-6.06-2.el7.noarch >>> ---> Paquete perl-Net-SMTP-SSL.noarch 0:1.01-13.el7 debe ser instalado >>> ---> Paquete perl-URI.noarch 0:1.60-9.el7 debe ser instalado >>> --> Procesando dependencias: perl(Business::ISBN) para el paquete: perl-URI-1.60-9.el7.noarch >>> ---> Paquete perl-WWW-RobotRules.noarch 0:6.02-5.el7 debe ser instalado >>> --> Ejecutando prueba de transacción >>> ---> Paquete ldirectord.x86_64 0:3.9.5-3.3 debe ser instalado >>> --> Procesando dependencias: perl-Net_SSLeay para el paquete: ldirectord-3.9.5-3.3.x86_64 >>> ---> Paquete perl-Business-ISBN.noarch 0:2.06-2.el7 debe ser instalado >>> --> Procesando dependencias: perl(Business::ISBN::Data) >= 20120719.001 para el paquete: perl-Business-ISBN-2.06-2.el7.noarch >>> ---> Paquete perl-Compress-Raw-Zlib.x86_64 1:2.061-4.el7 debe ser instalado >>> ---> Paquete perl-HTML-Tagset.noarch 0:3.20-15.el7 debe ser instalado >>> ---> Paquete perl-IO-Compress.noarch 0:2.061-2.el7 debe ser instalado >>> --> Procesando dependencias: perl(Compress::Raw::Bzip2) >= 2.061 para el paquete: perl-IO-Compress-2.061-2.el7.noarch >>> ---> Paquete perl-IO-HTML.noarch 0:1.00-2.el7 debe ser instalado >>> ---> Paquete perl-IO-Socket-SSL.noarch 0:1.94-3.el7 debe ser instalado >>> --> Procesando dependencias: perl(IO::Socket::IP) >= 0.20 para el paquete: perl-IO-Socket-SSL-1.94-3.el7.noarch >>> --> Procesando dependencias: perl(Net::LibIDN) para el paquete: perl-IO-Socket-SSL-1.94-3.el7.noarch >>> --> Ejecutando prueba de transacción >>> ---> Paquete ldirectord.x86_64 0:3.9.5-3.3 debe ser instalado >>> --> Procesando dependencias: perl-Net_SSLeay para el paquete: ldirectord-3.9.5-3.3.x86_64 >>> ---> Paquete perl-Business-ISBN-Data.noarch 0:20120719.001-2.el7 debe ser instalado >>> ---> Paquete perl-Compress-Raw-Bzip2.x86_64 0:2.061-3.el7 debe ser instalado >>> ---> Paquete perl-IO-Socket-IP.noarch 0:0.21-4.el7 debe ser instalado >>> ---> Paquete perl-Net-LibIDN.x86_64 0:0.12-15.el7 debe ser instalado >>> --> Resolución de dependencias finalizada >>> Error: Paquete: ldirectord-3.9.5-3.3.x86_64 (network_ha-clustering_Stable) >>> Necesita: perl-Net_SSLeay >>> Podría intentar utilizar el comando --skip-broken para sortear el problema >>> Podría intentar ejecutar: rpm- Va --nofiles --nodigest As you can see here the package "perl-Net_SSLeay" does not exists, but it's called "perl-Net-SSLeay" instead: >>> [root@galeno ~]# yum search perl-Net_SSLeay >>> Complementos cargados:fastestmirror, langpacks >>> Loading mirror speeds from cached hostfile >>> * base: ftp.uma.es >>> * epel: nl.mirror.eurid.eu >>> * extras: ftp.uma.es >>> * updates: ftp.cixug.es >>> Aviso: No se ha encontrado ningún resultado para: perl-Net_SSLeay >>> No matches found >>> [root@galeno ~]# yum search perl-Net-SSLeay >>> Complementos cargados:fastestmirror, langpacks >>> Loading mirror speeds from cached hostfile >>> * base: ftp.uma.es >>> * epel: nl.mirror.eurid.eu >>> * extras: ftp.uma.es >>> * updates: ftp.cixug.es >>> ====================================== N/S matched: perl-Net-SSLeay ====================================== >>> perl-Net-SSLeay.x86_64 : Perl extension for using OpenSSL I suppose the same problem was present on CentOS 6 repository, as the package name it's corrected in CentOS 6 repository requirements for ldirectord package, so the problem should be solved the same way in CentOS 7 repository. Thanks in advanced. Un saludo. David Ruiz Estefanía Administrador de Sistemas Centro de Alta Disponibilidad Correo: cad.ext(a)riojasalud.es Teléfono: +34 941 298 000 - Ext. 84743 Móvil: +34 669 432 808 ________________________________ GOBIERNO DE LA RIOJA AVISO LEGAL: La información contenida en este mensaje es confidencial y está destinada a ser leída sólo por la persona a la que va dirigida. Si Ud. no es el destinatario señalado le informamos que está prohibida, y puede ser ilegal, cualquier divulgación o reproducción de este mensaje. Antes de imprimir este e-mail piense bien si es necesario hacerlo. -- To unsubscribe, e-mail: opensuse-ha+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-ha+owner(a)opensuse.org

2 3

[opensuse-ha] ext4 failure on cluster
by steve 19 Aug '14

19 Aug '14

[post to both lists] Hi everyone Next month we hope to go into production with our drbd-ocfs2-ctdb cluster. Of course, we must prove to our boss that it is a fair if not better replacement for our single AD domain file-server which it will replace. A few questions remain to which we cannot find a simple answer that a non technical person would understand. Indeed, much of what we've read we cannot understand ourselves as self styled ha setter-uppers: 1. Where our single ext4 file server is predictable under load (it just gets slower), with both nodes up, why does the cluster fail so badly under ext4 but absolutely screams under ocfs2? The strange thing is that the clustered ext4 actually performs better when only one node is up. 2. Following what is happening with vbox and mysql, are Oracle likely to re-licence ocfs2 in the same way any time soon? 3. IF (2), do openSUSE or anyone else plan a fork (thinking e.g. mariadb)? General chit-chat/verbose/historical answers especially welcome. Thanks, L & S pp all the Linux team here in Alicante. -- To unsubscribe, e-mail: opensuse-ha+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-ha+owner(a)opensuse.org

8 29

[opensuse-ha] subscribe
by Wayne Green 19 Jul '14

19 Jul '14

-- To unsubscribe, e-mail: opensuse-ha+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-ha+owner(a)opensuse.org

1 0

[opensuse-ha] rsync between ext4 and ocfs2
by steve 16 Jul '14

16 Jul '14

13.1 with ha repo Hi I'm trying to debug a possible acl issue. I synced the roaming profiles for some windows boxes from our old single file server on ext4 to our cluster on ocfs2: rsync -AXauzv /home/users/profiles/* /cluster/users/profiles /cluster are our ocfs2 disks Some but not all the profiles are readable from the cluster and I notice that the ones with do not are the ones without the + in the directory listing (the + showing the extended acl), although the + existed on the ext4 source. New profiles are always created correctly. The cluster acl looks OK: /dev/drbd1 on /cluster type ocfs2 (rw,relatime,_netdev,heartbeat=local,nointr,data=ordered,errors=remount-ro,atime_quantum=60,coherency=full,user_xattr,acl) Question: can I rsync between file systems with rsync like this? Cheers, Steve -- To unsubscribe, e-mail: opensuse-ha+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-ha+owner(a)opensuse.org

1 0

[opensuse-ha] ctdb: do not start nmb
by steve 14 Jul '14

14 Jul '14

Hi We're in AD and so do not need nmbd. We have tried to disable it: systemctl disable nmb but ctdb insists on starting it when the node is enabled. Thanks, Steve -- To unsubscribe, e-mail: opensuse-ha+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-ha+owner(a)opensuse.org

2 2

[opensuse-ha] ctdb public_addesses bonding
by steve 13 Jul '14

13 Jul '14

13.1 with factory ha repo (the one with drbd 8.4 and ctdb 2.5) Hi I created a bond interface to a fixed nic, enp0s3 (enp0s3 is the slave) and as a guess, I set the latter to start 'on hotplug' using Yast. The documentation suggests both 'Never' and 'On boot' are necessary, depending upon what version of SLES you are using. I can't find anything 13.1 specific. It works, but do we have an official guidelines for this? Thanks, Steve -- To unsubscribe, e-mail: opensuse-ha+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-ha+owner(a)opensuse.org

1 0

[opensuse-ha] ctdb PARTIALLYONLINE problem
by steve 11 Jul '14

11 Jul '14

drbd ctdb ocfs2 on 13.1 Hi Everything seems OK apart from the IP takeover. public_addresses 192.168.1.80/24 enp0s3 192.168.1.81/24 enp0s3 ctdb status Number of nodes:2 pnn:0 192.168.1.10 PARTIALLYONLINE pnn:1 192.168.1.11 PARTIALLYONLINE (THIS NODE) Generation:2090727463 Size:2 hash:0 lmaster:0 hash:1 lmaster:1 Recovery mode:NORMAL (0) Recovery master:1 but we are getting: 2014/07/11 18:17:37.313940 [recoverd:15925]: Failed to find node to cover ip 192.168.1.81 2014/07/11 18:17:37.314608 [recoverd:15925]: Failed to find node to cover ip 192.168.1.80 our nodes are on the other interface, enps08: 192.168.1.10 192.168.1.11 At the moment, enp0s3 have fixed IPs: 192.168.1.82 192.168.1.83 Question: how do we configure the interface for the public IPs? Dow we need a third interface for the public ips? Cheers, Steve -- To unsubscribe, e-mail: opensuse-ha+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-ha+owner(a)opensuse.org

1 0

[opensuse-ha] Samba AD domain + CTDB
by steve 08 Jul '14

08 Jul '14

13.1 nodes with drbd and ocfs2 from the ha-factory repo. Hi First time here so please be gentle. Aim: add second failover file server for our AD domain. First time here so please be gentle. We have drbd and ocfs2 up on 2 nodes. We want to add ctbd on top of that for failover. The documentation: https://ctdb.samba.org/samba.html makes no mention of AD. In particular, how to join the cluster to the domain. 1. What next? Do we go straight to configure ctdb? 2. Is the 13.1 ctdb OK? 3. Does it work in AD? 4. Do we have any openSUSE specific samba cluster stuff? Thanks, Steve -- To unsubscribe, e-mail: opensuse-ha+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-ha+owner(a)opensuse.org

2 6

[opensuse-ha] Re: [opensuse-factory] ha-networking repo error
by Richard Brown 05 Jul '14

05 Jul '14

On 5 July 2014 10:46, lynn <lynn(a)steve-ss.com> wrote: > On Fri, 2014-07-04 at 13:25 +0200, lynn wrote: >> On Fri, 2014-07-04 at 10:35 +0200, lynn wrote: >> > 13.1 >> > Hi >> > I need a copy of drbd 8.4 so I did a one click install from opensuse.org >> > >> > But I get this error: >> > An error occurred while initializing the software repository. >> > Details: >> > network:ha-clustering:Factory: [|] Valid metadata not found at specified >> > URL >> > History: >> > - File /var/tmp/TmpFile.9qpP14 doesn't contain public key data >> > >> > Try again? >> > >> > At this url: >> > http://download.opensuse.org/repositories/network:/ha-clustering:/Factory/o… >> > >> > 1. Could someone put 'Valid metadata' to satisfy yast? >> > 2. Any other recommended drdb 8.4 repos? >> > Thanks, >> > L x >> > >> > >> >> Is it a fault here maybe? >> >> 2014-07-04 12:56:04 <1> altea(1639) [zypp++] >> MediaCurl.cc(doGetDoesFileExist):1085 URL: >> http://download.opensuse.org/repositories/network:/ha-clustering:/openSUSE_… >> 2014-07-04 12:56:05 <1> altea(1639) [zypp] >> MediaCurl.cc(doGetDoesFileExist):1166 perform code: 22 [ HTTP response >> code said error ] >> 2014-07-04 12:56:05 <5> altea(1639) [zypp] Exception.cc(log):137 >> MediaCurl.cc(evaluateCurlCode):1000 THROW: File >> '/repodata/repomd.xml' not found on medium >> 'http://download.opensuse.org/repositories/network:/ha-clustering:/openSUSE_…' >> 2014-07-04 12:56:05 <5> altea(1639) [zypp] Exception.cc(log):137 >> 2014-07-04 12:56:05 <5> altea(1639) [zypp] Exception.cc(log):137 >> MediaCurl.cc(evaluateCurlCode):1062 RETHROW: File >> '/repodata/repomd.xml' not found on medium >> 'http://download.opensuse.org/repositories/network:/ha-clustering:/openSUSE_…' >> 2014-07-04 12:56:05 <5> altea(1639) [zypp] Exception.cc(log):137 >> 2014-07-04 12:56:05 <1> altea(1639) [zypp++] >> MediaManager.cc(checkDesired):112 checkDesired(13): desired (cached) >> 2014-07-04 12:56:05 <1> altea(1639) [zypp++] >> MediaSetAccess.cc(provide):203 Going to try to provide file /content >> from media number 1 >> 2014-07-04 12:56:05 <1> altea(1639) [zypp++] >> MediaManager.cc(checkDesired):112 checkDesired(13): desired (cached) >> 2014-07-04 12:56:05 <1> altea(1639) [zypp++] >> MediaCurl.cc(doGetDoesFileExist):1075 /content >> 2014-07-04 12:56:05 <1> altea(1639) [zypp++] >> MediaCurl.cc(doGetDoesFileExist):1085 URL: >> http://download.opensuse.org/repositories/network:/ha-clustering:/openSUSE_… >> 2014-07-04 12:56:05 <1> altea(1639) [zypp] >> MediaCurl.cc(doGetDoesFileExist):1166 perform code: 22 [ HTTP response >> code said error ] >> 2014-07-04 12:56:05 <5> altea(1639) [zypp] Exception.cc(log):137 >> MediaCurl.cc(evaluateCurlCode):1000 THROW: File '/content' not found >> on medium >> 'http://download.opensuse.org/repositories/network:/ha-clustering:/openSUSE_…' >> 2014-07-04 12:56:05 <5> altea(1639) [zypp] Exception.cc(log):137 >> 2014-07-04 12:56:05 <5> altea(1639) [zypp] Exception.cc(log):137 >> MediaCurl.cc(evaluateCurlCode):1062 RETHROW: File '/content' not found >> on medium >> 'http://download.opensuse.org/repositories/network:/ha-clustering:/openSUSE_…' >> 2014-07-04 12:56:05 <5> altea(1639) [zypp] Exception.cc(log):137 >> 2014-07-04 12:56:05 <1> altea(1639) [zypp++] >> MediaManager.cc(checkDesired):112 checkDesired(13): desired (cached) >> 2014-07-04 12:56:05 <1> altea(1639) [zypp++] >> MediaSetAccess.cc(release):434 Releasing all media IDs held by this >> MediaSetAccess >> 2014-07-04 12:56:05 <1> altea(1639) [zypp++] >> MediaManager.cc(release):486 release(id=13) >> 2014-07-04 12:56:05 <1> altea(1639) [zypp++] >> MediaHandler.cc(release):734 Request to release attached media >> http<http://download.opensuse.org/repositories/network:/ha-clustering:/openSUSE_…>, use count=1 >> 2014-07-04 12:56:05 <1> altea(1639) [zypp++] >> MediaHandler.cc(release):741 Releasing media >> http<http://download.opensuse.org/repositories/network:/ha-clustering:/openSUSE_…> >> 2014-07-04 12:56:05 <1> altea(1639) [zypp] >> MediaHandler.cc(disconnect):713 Disconnected: >> http://download.opensuse.org/repositories/network:/ha-clustering:/openSUSE_… attached; localRoot "/var/adm/mount/AP_0xtn8DZ5" >> 2014-07-04 12:56:05 <1> altea(1639) [zypp++] >> MediaHandler.cc(removeAttachPoint):179 MediaHandler - checking if to >> remove attach point >> 2014-07-04 12:56:05 <1> altea(1639) [zypp] >> PathInfo.cc(recursive_rmdir):430 >> recursive_rmdir /var/adm/mount/AP_0xtn8DZ5 >> 2014-07-04 12:56:05 <1> altea(1639) [zypp] >> MediaHandler.cc(removeAttachPoint):191 Deleted default attach >> point /var/adm/mount/AP_0xtn8DZ5 >> 2014-07-04 12:56:05 <1> altea(1639) [zypp] MediaHandler.cc(release):795 >> Released: >> http://download.opensuse.org/repositories/network:/ha-clustering:/openSUSE_… not attached; localRoot "" >> >> > > Anyone? > Hi Lynn, I'm going to CC this email to opensuse-ha(a)opensuse.org - you probably should be asking questions like this, and your other HA related one, there rather than here - this list is primarily for discussions about the 'next release of openSUSE' and I suppose also now the 'Factory rolling release of openSUSE' - a drdb module for openSUSE 13.1 doesn't fit into either of those categories :) I cant reproduce this myself, neither can some of the HA maintainers who I asked to check this out for you. Is it possible you're using a broken mirror? You might want to take a look at http://mirrors.opensuse.org/ and manually change your repository to a different mirror (make sure it's one that has 'BS' selected, as we're talking about the build service in this case) Regards, Richard -- To unsubscribe, e-mail: opensuse-ha+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-ha+owner(a)opensuse.org

1 0

[opensuse-ha] Re: [opensuse-factory] drbd problems
by Richard Brown 05 Jul '14

05 Jul '14

Hi Lynn, I'm going to CC this email to opensuse-ha(a)opensuse.org - you probably should be asking questions like this, and your other HA related one, there rather than here - this list is primarily for discussions about the 'next release of openSUSE' and I suppose also now the 'Factory rolling release of openSUSE' - a drdb module for openSUSE 13.1 doesn't fit into either of those categories :) Now onto your problem drbd.ko should be getting installed, it certainly seems to have built happily and healthily for openSUSE 13.1 according to https://build.opensuse.org/package/show/network:ha-clustering:Factory/drbd What does rpm -ql show for the drbd package? Regards Richard On 5 July 2014 18:33, lynn <lynn(a)steve-ss.com> wrote: > 13.1 > Hi > drbd which comes with 13.1 is broken so I tried the factory repo here: > > http://download.opensuse.org/repositories/network:/ha-clustering:/Factory/o… > > But this has a module missing: > FATAL: Could not read > '/lib/modules/3.11.10-17-default/weak-updates/updates/drbd.ko': No such > file or directory > > I see in that directory that drbd.ko is a link to an older kernel: > smb1:/lib/modules/3.11.10-17-default/weak-updates/updates # ls -l > total 0 > lrwxrwxrwx 1 root root 45 Jul 5 17:19 drbd.ko > -> /lib/modules/3.11.6-4-default/updates/drbd.ko > > BUT, drbd.ko is not present there either. > > Do we have any version of drbd which is working? > Thanks, > L x > > > -- > To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org > To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org > -- To unsubscribe, e-mail: opensuse-ha+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-ha+owner(a)opensuse.org

1 0

[opensuse-ha] Support for the kdumpcheck STONITH plugin in HAE
by Ron Kerry 02 Apr '14

02 Apr '14

We have a customer that has requested that Novell provide full support for the kdumpcheck STONITH plugin in SLE-HAE. The plugin is documented in the SLE HAE manual in section 9.5 "Special Fencing Devices". http://doc.opensuse.org/products/draft/SLE-HA/SLE-ha-guide_sd_draft/cha.ha.… external/kdumpcheck This plug-in checks if a Kernel dump is in progress on a node. If so, it returns true, and acts as if the node has been fenced. The node cannot run any resources during the dump anyway. This avoids fencing a node that is already down but doing a dump, which takes some time. The plug-in must be used in concert with another, real STONITH device. For more details, see /usr/share/doc/packages/cluster-glue/README_kdumpcheck.txt. The plugin is also provided as part of the sle-ha pattern set of packages. However, the plugin requires a patch to mkdumprd that is not present in the SLES distribution. There is some history in SLES bugzilla associated with this plugin and mkdumprd. https://bugzilla.novell.com/show_bug.cgi?id=445870 Essentially, mkdumprd is a RHEL mechanism, so Novell will need to figure out the equivalent changes to enable use of this STONITH plugin. As it is, it is not usable despite being present and documented in the HAE Guide. Note that the real requirement here is some sort of robust mechanism to allow a crash dump to take place when HA is active with STONITH enabled. Is there some other supported way to do this? Can kdumpcheck be made to work in a SLES11 SP3 HAE environment? -- Ron Kerry -- To unsubscribe, e-mail: opensuse-ha+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-ha+owner(a)opensuse.org

2 2

[opensuse-ha] drbd and heartbeat (or others)
by Per Jessen 16 Jan '14

16 Jan '14

I'm setting up a pair of frontend nodes with a drbd device. The drbd will have LVM on top and the LVs will be shared out to other systems (backends) via iSCSI. I'm very new to drbd, although I did play with it some years ago. In order to make a node the primary, it seems I need heartbeat (or something else) to manage it? Presumably I can also add the lvm commands somehwere. The drbd website recommends pacemaker, which says it is built on corosync or heartbeat. My question is - this seems like quite a bit of work for just making sure one node is the primary, is there no simple approach? -- Per Jessen, Zürich (3.2°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse-ha+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-ha+owner(a)opensuse.org

2 3

[opensuse-ha] OpenAIS RPM missing in openSUSE 13.1?
by Thomas Schulte 26 Nov '13

26 Nov '13

Hi! Although this mailing list doesn't seem to be well-frequented, I'm hoping to get a hint here: I am (was) running a 2-node cluster with openSUSE 12.3. Pacemaker, Corosync, OpenAIS and so on. Everything was working almost fine. Today I set one node offline to migrate it to openSUSE 13.1. After successfully installing all packages and rebooting the system, I noticed that the openais RPM seems to be missing. It's not included in repo-oss, although it should be (as said on this page: https://en.opensuse.org/openSUSE:High_Availability). I switched to network:ha-clustering:Factory, but there's still no openais package found. Did the openais package got lost on it's way to openSUSE 13.1 or do I need to configure my cluster-node with different tools? I couldn't find any news about this in the release notes. Any hint is welcome. Regards, Thomas -- E-Mail: thomas(a)cupracer.de Web: http://www.mynakedgirlfriend.de

2 2

[opensuse-ha] multicast problems with cluster of KVM guests
by Tim Serong 27 Sep '13

27 Sep '13

Hi All, I spent quite some time last week bashing my head against a weird multicast problem. I have openSUSE 12.3 on my desktop, running a cluster of openSUSE 13.1 beta VMs, configured for multicast. After a while one then the other node would start spewing "corosync [TOTEM] Retransmit List: ..." to syslog, and the cluster would break. This seems to be the same issue discussed here: https://bugzilla.redhat.com/show_bug.cgi?id=880035 If anyone else hits this problem, you can work around it by running the following command on the host: # echo 1 > /sys/class/net/virbr0/bridge/multicast_querier Substitute your bride interface name for "virbr0" as appropriate. Alternately, configure the cluster to use udpu instead of multicast. I've also added this to the wiki page at http://en.opensuse.org/openSUSE:High_Availability Regards, Tim -- Tim Serong Senior Clustering Engineer SUSE tserong(a)suse.com -- To unsubscribe, e-mail: opensuse-ha+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-ha+owner(a)opensuse.org

1 0

[opensuse-ha] Welcome to opensuse-ha
by Tim Serong 17 Sep '13

17 Sep '13

Greetings, Welcome to opensuse-ha. This list is for discussion of high availability clustering on openSUSE. This includes: - The base cluster stack, i.e. corosync and pacemaker - Management tools such as crmsh and hawk - Clustered filesystems (e.g.: ocfs2) - Replicated storage (drbd) - Basically, anything in network:ha-clustering:* on OBS is on topic :) Please also see the wiki page at: https://en.opensuse.org/openSUSE:High_Availability Happy clustering! Tim -- Tim Serong Senior Clustering Engineer SUSE tserong(a)suse.com -- To unsubscribe, e-mail: opensuse-ha+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-ha+owner(a)opensuse.org

1 0