Thanks! I'm looking forward to seeing these fixes hit the Fedora repo :)
On Sat, Jun 2, 2018 at 8:07 AM, Mark Reynolds wrote:
> I was right I did fix all the ARM issues, but not in 1.3.8, only in
> 1.4.0. It was a large change though that required a few patches. I'll see
> what I can do about
I was right I did fix all the ARM issues, but not in 1.3.8, only in
1.4.0. It was a large change though that required a few patches. I'll
see what I can do about backporting the changes...
On 06/01/2018 05:38 PM, Jonathan Vaughn wrote:
Created https://pagure.io/389-ds-base/issue/49746
I'll
Created https://pagure.io/389-ds-base/issue/49746
I'll get you the build log once it's done building without the patch.
On Fri, Jun 1, 2018 at 3:54 PM, Mark Reynolds wrote:
>
>
> On 06/01/2018 04:32 PM, Jonathan Vaughn wrote:
>
> Alright, I think I've got everything* working. (* Not running the
On 06/01/2018 04:32 PM, Jonathan Vaughn wrote:
Alright, I think I've got everything* working. (* Not running the CA
server on the Arm device, not tested, but from what I've read before I
would need to adjust the startup timeout since OpenJDK is so slow).
1) I removed the Arm replica from the
Alright, I think I've got everything* working. (* Not running the CA server
on the Arm device, not tested, but from what I've read before I would need
to adjust the startup timeout since OpenJDK is so slow).
1) I removed the Arm replica from the cluster and reimaged the device
entirely and started
Anyone have any further suggestions for troubleshooting this issue with the
web UI?
On Fri, May 18, 2018 at 4:01 PM, Jonathan Vaughn
wrote:
> httpd error_log
>
> [Fri May 18 15:58:29.546255 2018] [wsgi:error] [pid 14004:tid 2903716672]
> [remote 10.10.11.3:59284] ipa: DEBUG: WSGI wsgi_dispatch._
httpd error_log
[Fri May 18 15:58:29.546255 2018] [wsgi:error] [pid 14004:tid 2903716672]
[remote 10.10.11.3:59284] ipa: DEBUG: WSGI wsgi_dispatch.__call__:
[Fri May 18 15:58:29.547217 2018] [wsgi:error] [pid 14004:tid 2903716672]
[remote 10.10.11.3:59284] ipa: DEBUG: WSGI login_password.__call__:
Jonathan Vaughn wrote:
> System time appears to be fine.
>
> Here's the httpd access log (nothing in error log):
> 10.10.255.101 - - [18/May/2018:15:26:19 -0500] "GET /ipa/session/cookie
> HTTP/1.1" 301 260 "-" "python-requests/2.18.4"
> 10.10.255.101 - admin@CREATUITY.INTERNAL [18/May/2018:15:26:
Sorry, missed your build instructions, only saw them just now. I've just
kicked off that build and I'll check it tomorrow once I'm back in.
One note, it appears it's ./autogen.sh not ./autogen.pl ...
On Thu, May 17, 2018 at 6:16 PM, Jonathan Vaughn
wrote:
> Welp, I'm still getting the -fPIC err
Welp, I'm still getting the -fPIC error ... so I may need to figure out how
to do it with COPR or something.
On Thu, May 17, 2018 at 4:16 PM, Jonathan Vaughn
wrote:
> I've never used COPR. I've dabbled with RPMs in the past but that was...
> CentOS 6 I think, and I wasn't making source code chan
I've never used COPR. I've dabbled with RPMs in the past but that was...
CentOS 6 I think, and I wasn't making source code changes so much as just
copying and pasting SRPMs from another RPM platform to build for CentOS,
using the regular rpmbuild stuff.
I did actually try just copying the configur
Jonathan Vaughn via FreeIPA-users wrote:
> Oops, hit reply instead of reply-all
>
> NSPR RPMs
>
> # yum list installed nspr*
> Installed Packages
> nspr.armv7hl
> 4.19.0-1.fc27
>
Oops, hit reply instead of reply-all
NSPR RPMs
# yum list installed nspr*
Installed Packages
nspr.armv7hl
4.19.0-1.fc27
@updates
nspr-debuginfo.armv7hl
4.19.0-1.fc27
@updates-debuginfo
nspr-debugsource.armv7hl
4.19.0-1.fc27
@updates-debuginfo
nspr-devel.armv7hl
4.
On 05/16/2018 10:03 PM, Jonathan Vaughn wrote:
I've been just using the packages from Fedora. I can build it
potentially but I don't have a cross build environment set up at the
moment. From experience I'd want to do that first because building
anything on the Pi usually takes ages.
I'd bee
I've been just using the packages from Fedora. I can build it potentially
but I don't have a cross build environment set up at the moment. From
experience I'd want to do that first because building anything on the Pi
usually takes ages.
I'd been "redacting" the hostnames but I'll stop bothering si
On 05/16/2018 03:43 PM, Jonathan Vaughn wrote:
> The installed version of 389* is 1.3.7.10-1.fc27 for armv7hl, which
> appears to be the latest available version.
Perhaps something is off with the inttypes on Raspberry. Are you
building this yourself on Raspberry? Can we make code changes and
The installed version of 389* is 1.3.7.10-1.fc27 for armv7hl, which appears
to be the latest available version.
On Wed, May 16, 2018 at 2:38 PM, Jonathan Vaughn
wrote:
> (gdb) up
> #1 0xb6926b40 in cvt_s (flags=0, prec=, width=0, str=0x4
> , ss=)
> at ../../.././nspr/pr/src/io/prprf.c:374
>
(gdb) up
#1 0xb6926b40 in cvt_s (flags=0, prec=, width=0, str=0x4
, ss=)
at ../../.././nspr/pr/src/io/prprf.c:374
374 slen = strlen(str);
(gdb) up
#2 dosprintf (ss=ss@entry=0x9e06e4bc, fmt=0xb34b0df2 "", fmt@entry=0xb34da770
"\360\317p\002", ap=...) at
../../.././nspr/pr/src/io/p
This looks really familiar and I thought it was fixed. It should have
been fixed in 1.3.7.10-1 (https://pagure.io/389-ds-base/issue/49618).
In your debug session go "up" into agmt_maxcsn_update() and do:
(gdb) p *agmt
Then send us that output please.
Thanks,
Mark
On 05/15/2018 05:29 PM, Jona
Here is a backtrace from live gdb after the segfault. Looks like things
went wrong somewhere during in the replication code ?
Thread 36 "ns-slapd" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x9e0bc280 (LWP 4662)]
strlen () at ../sysdeps/arm/armv6t2/strlen.S:142
142
Hi Jonathan,
This problem looks new to me and has something specific to your environment.
I think the best approach is to continue to debug on your system if you
have the possibility to do so.
From strace we can see that DS started smoothly (created its pid file
then notified systemd it was r
Here's a strace from before it dies. Most of the elapsed time is it waiting
on some futex call it looks like near the end, when it finally "returns"
(from lack of strace output for duration of call I assume it didn't
actually return but SIGSEGV in that call) and strace prints ' = ?' on the
futex it
Hi Jonathan,
This is weird as the crashing thread stack looks truncated (did you
copy/paste all of it ?)
Thread 1 (Thread 0x9e13c280 (LWP 17245)):
#0 0xb67bbf2e in strlen () at /lib/libc.so.6
#1 0xb6a06b40 in dosprintf () at /lib/libnspr4.so
#2 0x in None ()
Did you install 389-ds-
Jonathan Vaughn via FreeIPA-users wrote:
Still trying to figure this out. It looks like slapd is dying, I thought
it was still running for some reason.
slapd is dying to segfault. strace of it happening doesn't seem to
reveal much:
A stack trace would very much help trying to track down the
Could this be part of the problem now?
[root@ipa-12 master]# ipa-replica-manage list ipa-12.company.internal
ipa-11.company.internal: replica
ipa-13.company.internal: replica
[root@ipa-12 master]# ipa-replica-manage list ipa-13.company.internal
ipa-11.company.internal: replica
ipa-12.company.inter
Still trying to figure this out. It looks like slapd is dying, I thought it
was still running for some reason.
slapd is dying to segfault. strace of it happening doesn't seem to reveal
much:
18:32:41.543717 (+ 0.000801) openat(AT_FDCWD,
"/var/run/dirsrv/slapd-COMPANY-INTERNAL.pid", O_WRONLY|O
It's still running.
Here's the error log from slapd during that run:
[01/May/2018:19:22:24.567650453 -0500] - ERR - NSMMReplicationPlugin -
multimaster_extop_StartNSDS50ReplicationRequest - conn=42 op=5
replica="dc=company,dc=internal": Unable to acquire replica: error:
permission denied
[01/May/
Jonathan Vaughn wrote:
Here's the output from ipa-replica-install :
# ipa-replica-install
WARNING: conflicting time&date synchronization service 'chronyd' will
be disabled in favor of ntpd
Password for admin@COMPANY.INTERNAL:
Run connection check to master
Connection check OK
Configuring NTP da
Jonathan Vaughn via FreeIPA-users wrote:
Yes, I know, not recommended etc, low performance. I'm not going to run
the CA on it. I just want to have a backup LDAP/Kerberos server.
Right now I'm just trying to test things out. I've got a master and a
replica (so you could say two masters I suppos
29 matches
Mail list logo