- 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