Re: Update to libdb-5.3.28-21.fc25 in F25 will break the rpm database. Repairable by rebuilding rpm database with rpm --rebuilddb

[Samuel Sieb]

On 06/09/2017 07:29 PM, Ed Greshko wrote:

On 06/10/17 10:22, Ed Greshko wrote:

FWIW, so far I've seen no ill effects from updating to
libdb-5.3.28-21.fc25.  However, I should note that I had previously
updated to libdb-5.3.28-16 from testing also with no ill effects.


Oh, I just realized I updated a second system to libdb-5.3.28-21.fc25
but it hadn't been updated from the testing repository.  No problems for
me with that update either.


My observations of the discussions indicate that it depends on the 
packages that are getting updated.  Some packages try to run rpm during 
the installation process and that is where the problem happens.

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: Fedora Alpha , Beta and general release software release

[Peter Gueckel]

Ed Greshko wrote:

> On 06/10/17 07:55, Timothy Ward wrote:
>> Do you have to upgrade Alpha to Beta and then to general 
release
>> version software as it becomes available or is it upgraded 
to the
>> latest available version as Beta or general release becomes 
available.
> 
> 
> No, you don't have to do that.  As a matter of fact, unless 
you are
> "testing" and are willing to suffer data loss or an unstable 
and
> potentially broken system you should probably avoid Alpha 
and Beta
> releases.
> 
> In most instances it is safer for the average user to update 
their
> systems to the next version after the next version is 
formally released.

Fedora 26 was very solid and usable right from the release of 
the Alpha. Unfortunately, the previous 2-3 releases did not 
become usable until the Beta or even the Release Candidates, 
but I have found this to be very atypical of Fedora. I am glad 
that the quality control is back to where it has been in the 
past. In fact, I read that for Fedora 27, there will no longer 
be an Alpha, as Quality will be maintained throughout.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: post-mortem: f24 boot fails; need help.

[William Mattison]

I think you're probably right on both counts.  I thought so before my Thursday 
night post, but really thought it best to check with the experts.

thanks,
Bill.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: post-mortem: f24 boot fails; need help.

[William Mattison]

It's believed that the main problems were i-node problems identified by "fsck" 
during boot.  The first time, they were on sda6; the second time, they were on 
sda7.

A few follow-up questions about the hard drive...  I used the long but 
non-destructive test options of both "badblocks" and "smartctl".  They each 
scan the entire hard drive, right?  If "dnf upgrade" were writing to new areas 
of the disk, and those areas were bad,
1. those writes would have failed, and in turn have caused the "dnf upgrade" to 
fail, right?
2. the "smartctl" and "badblocks" tests would have found and reported those bad 
areas right?

I only have one system, and only one hard drive, and no money to buy.

The hardware work was done between fixing the second occurrence of the problem 
and the upgrade from f24 to f25.  That upgrade would have done a lot more disk 
writing (and reading?) than did the two f24 weekly patches that preceded the 
boot failures.  This suggests - merely suggests - to me that the hardware work 
(re-doing cable connections, cleaning, etc.) fixed the problem rather than it 
being a problem within the hard drive.

thanks,
Bill.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: Update to libdb-5.3.28-21.fc25 in F25 will break the rpm database. Repairable by rebuilding rpm database with rpm --rebuilddb

[stan]

On Fri, 9 Jun 2017 18:20:39 -0700
Samuel Sieb  wrote:

> On 06/09/2017 06:12 PM, stan wrote:

> > rm /var/lib/rpm/__db.00?  # optional?

> That's not deleting the RPM database, just removing temporary files
> that rpm uses.

Thanks for the clarification.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: Update to libdb-5.3.28-21.fc25 in F25 will break the rpm database. Repairable by rebuilding rpm database with rpm --rebuilddb

[stan]

On Sat, 10 Jun 2017 10:22:17 +0800
Ed Greshko  wrote:


> FWIW, so far I've seen no ill effects from updating to
> libdb-5.3.28-21.fc25.  However, I should note that I had previously
> updated to libdb-5.3.28-16 from testing also with no ill effects.

I suppose the subject should be *might* break the rpm database.  I
wonder why it worked for you and not for me?  I have test-updates
enabled, so I should have followed the same path you did.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: Update to libdb-5.3.28-21.fc25 in F25 will break the rpm database. Repairable by rebuilding rpm database with rpm --rebuilddb

[Ed Greshko]

On 06/10/17 10:22, Ed Greshko wrote:
> On 06/10/17 09:12, stan wrote:
>> There is an update (or test update) of libdb for F25 that, when
>> installed, breaks the rpm database because it is incompatible.  The dnf
>> update completes, and then hangs (at least it did on my system).  The
>> fix is to remove the old rpm databases (this might be optional), and
>> rebuild the rpm databases.
>>
>> rm /var/lib/rpm/__db.00?  # optional?
>> rpm --rebuilddb
>>
>> I did a reboot to sync everything that uses libdb (anything that uses
>> the Berkeley db).  It might be possible just to restart affected
>> applications if that isn't an option.  That worked for my mail client
>> before I rebooted.
>
> FWIW, so far I've seen no ill effects from updating to
> libdb-5.3.28-21.fc25.  However, I should note that I had previously
> updated to libdb-5.3.28-16 from testing also with no ill effects.
>

Oh, I just realized I updated a second system to libdb-5.3.28-21.fc25
but it hadn't been updated from the testing repository.  No problems for
me with that update either.


-- 
Fedora Users List - The place to go to speculate endlessly



signature.asc
Description: OpenPGP digital signature
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: Update to libdb-5.3.28-21.fc25 in F25 will break the rpm database. Repairable by rebuilding rpm database with rpm --rebuilddb

[Ed Greshko]

On 06/10/17 09:12, stan wrote:
> There is an update (or test update) of libdb for F25 that, when
> installed, breaks the rpm database because it is incompatible.  The dnf
> update completes, and then hangs (at least it did on my system).  The
> fix is to remove the old rpm databases (this might be optional), and
> rebuild the rpm databases.
>
> rm /var/lib/rpm/__db.00?  # optional?
> rpm --rebuilddb
>
> I did a reboot to sync everything that uses libdb (anything that uses
> the Berkeley db).  It might be possible just to restart affected
> applications if that isn't an option.  That worked for my mail client
> before I rebooted.


FWIW, so far I've seen no ill effects from updating to
libdb-5.3.28-21.fc25.  However, I should note that I had previously
updated to libdb-5.3.28-16 from testing also with no ill effects.

-- 
Fedora Users List - The place to go to speculate endlessly



signature.asc
Description: OpenPGP digital signature
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: Update to libdb-5.3.28-21.fc25 in F25 will break the rpm database. Repairable by rebuilding rpm database with rpm --rebuilddb

[Samuel Sieb]

On 06/09/2017 06:12 PM, stan wrote:

There is an update (or test update) of libdb for F25 that, when
installed, breaks the rpm database because it is incompatible.  The dnf
update completes, and then hangs (at least it did on my system).  The
fix is to remove the old rpm databases (this might be optional), and
rebuild the rpm databases.

rm /var/lib/rpm/__db.00?  # optional?
rpm --rebuilddb


That's not deleting the RPM database, just removing temporary files that 
rpm uses.



I did a reboot to sync everything that uses libdb (anything that uses
the Berkeley db).  It might be possible just to restart affected
applications if that isn't an option.  That worked for my mail client
before I rebooted.


A reboot would be recommended, but restarting any affected applications 
should be sufficient.

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Update to libdb-5.3.28-21.fc25 in F25 will break the rpm database. Repairable by rebuilding rpm database with rpm --rebuilddb

[stan]

There is an update (or test update) of libdb for F25 that, when
installed, breaks the rpm database because it is incompatible.  The dnf
update completes, and then hangs (at least it did on my system).  The
fix is to remove the old rpm databases (this might be optional), and
rebuild the rpm databases.

rm /var/lib/rpm/__db.00?  # optional?
rpm --rebuilddb

I did a reboot to sync everything that uses libdb (anything that uses
the Berkeley db).  It might be possible just to restart affected
applications if that isn't an option.  That worked for my mail client
before I rebooted.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: postgresql and firewald startup

[Gordon Messmer]

On 06/09/2017 12:09 AM, Jeandet Alexis wrote:

On startup postgreslq always fail to start complaining about port 5432.



My first guess would be that you've configured postgresql to listen on a 
specific IP address, and when you do that, the service needs to depend 
on "network-online.target" instead of "network.target."


Run "systemctl edit postgresql.service" and insert two lines:

[Unit]
After=network-online.target
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: Fedora Alpha , Beta and general release software release

[Ed Greshko]

On 06/10/17 07:55, Timothy Ward wrote:
> Do you have to upgrade Alpha to Beta and then to general release
> version software as it becomes available or is it upgraded to the
> latest available version as Beta or general release becomes available.


No, you don't have to do that.  As a matter of fact, unless you are
"testing" and are willing to suffer data loss or an unstable and
potentially broken system you should probably avoid Alpha and Beta releases.

In most instances it is safer for the average user to update their
systems to the next version after the next version is formally released.

-- 
Fedora Users List - The place to go to speculate endlessly
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Fedora Alpha , Beta and general release software release

[Timothy Ward]

Do you have to upgrade Alpha to Beta and then to general release
version software as it becomes available or is it upgraded to the
latest available version as Beta or general release becomes available.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: postgresql and firewald startup

[Samuel Sieb]

On 06/09/2017 12:09 AM, Jeandet Alexis wrote:

I have a server running F25 with postgresql and firewald configured.
On startup postgreslq always fail to start complaining about port 5432. 
I did allow this port on the firewall, if I start manually postgresql 
after it works.


Can you paste the exact error?  Even if firewalld was running, it 
shouldn't block postgresql from listening on the port.

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: IP address or DNS name (bug or feature)

[Tim]

Gordon Messmer wrote:
>> In any case, if that solution isn't workable for you, you can remove 
>> "mdns4_minimal [NOTFOUND=return]" from /etc/nsswitch.conf, and you 
>> should be able to look up .local hosts using DNS.

Tom Horsley:
> On every system I've ever tried *all* dns lookups always
> fail if that mdns junk is in nsswitch. I always have to
> remove it to get any dns to work.

The converse, here.  I've never had to mess around removing mdns from
nsswitch.conf.  And I don't recall having to do anything *like* that
since I stopped using Samba years ago (removing lmhosts from the name
resolution equation).

I run a local DNS server, that's integrated with my DHCP server (in that
new hosts assigned an IP by the DHCP server get their data incorporated
into the DNS server, so all clients on my LAN use my DNS server for
*all* name resolution, local and WWW).  I don't make use of the hosts
file.

-- 
[tim@localhost ~]$ uname -rsvp
Linux 3.9.10-100.fc17.x86_64 #1 SMP Sun Jul 14 01:31:27 UTC 2013 x86_64 
(always current details of the computer that I'm writing this email on)

Boilerplate:  All mail to my mailbox is automatically deleted, there is
no point trying to privately email me, I only get to see the messages
posted to the mailing list.

Lucky for you I typed this, you'd never be able to read my handwriting.


___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: post-mortem: f24 boot fails; need help.

[Tim]

Allegedly, on or about 09 June 2017, William Mattison sent:
> * Hard drive?  Somewhat unlikely.  Two 4-hour non-destructive disk
> checks found no issues.  System cleaned; cables dis- and re-connected;
> hard drive removed and put back in; no kinky cables seen.  Destructive
> testing and replacing the hard drive are not options for me at this
> time.  Circumstances suggest such would be over-kill.

Still possible.  The unrecoverable errors may be on some part of the
drive that you're not reading files from, they may not.  Those errors
could have been caused by the drive (surface faults, firmware faults),
or external factors (fixed by reseating a cable, caused by some random
glitch that hasn't happened again, etc).

> * Somehow caused by the "dnf upgrade"?

I'd be surprised if a changed version of some software caused that kind
of error.  Not surprised if the action of writing data (any file, no
matter what it was) to a new areas of a drive could find a previously
undetected fault.

In the past, we used to format and check drives before installing, to
discover these little nasties.  These days, mostly thanks to drives
being huge and checks taking forever, the checking step gets omitted
(it's no longer an option in the installer).

> * Power supply?  Somewhat unlikely.  I know of no way to test this.
> But Tim's analysis and other circumstances suggest it's not worth
> pursuing this possibility any further.

Still possible to be a power supply problem.  Power supplies can go bad.
They can work normally under certain loads, then fail as loads increase
(e.g. heavier CPU work).  They can randomly glitch, switchmode power
supplies are hardly the most reliable design.

A perfectly fine power supply could be glitched by external factors,
such as mains power brown-outs, other equipment starting up (fridges,
air-conditioners).

You're really only going to find the true cause if you can make it
happen again.

Going from what I remember of the thread, the main problem was due to
some unrecoverable read error on the drive.  At some stage they were
probably in an area of the drive that was read at boot-up.  Sometimes a
drive can eventually recover from them, it does try over-and-over, but
usually it would have recovered straight away, if it could.  If the
drive still has those bad sections, if they can't be cleared by
rewriting to the drive, the drive is probably the issue.

If you have a spare drive, I'd put it in and give the old one a thorough
test.

-- 
[tim@localhost ~]$ uname -rsvp
Linux 3.9.10-100.fc17.x86_64 #1 SMP Sun Jul 14 01:31:27 UTC 2013 x86_64 
(always current details of the computer that I'm writing this email on)

Boilerplate:  All mail to my mailbox is automatically deleted, there is
no point trying to privately email me, I only get to see the messages
posted to the mailing list.

Evolution keeps on telling me that it's refreshing, but I still want to
go and get a drink.


___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: Mailman is broken

[Tim]

Allegedly, on or about 09 June 2017, Ed Greshko sent:
> Probably, eventually.   After I study the differences between the
> headers of an S/MIME message to the list compared with the headers of
> a PGP/MIME message (which I have verified does survive) and determine
> if it is a case of real breakage or a case of Thunderbird not doing
> the right thing.
> 
> So, I need to know more about S/MIME, PGP/MIME, the abilities of
> Thunderbird, and then the mechanics of mailman before I can somewhat
> intelligently talk about it.  :-)
> 
> (FWIW, this message is signed with S/MIME from within Thunderbird) and
> the message you replied to was signed with PGP/MIME. 

That one came through, okay.  Having a look at the source of the
message, the list added it's signature as another section to the mail.
The different parts of the mail have individualised headers that tell
each section apart, as well as which parts are associated with each
other.  And, by the converse, the boundary marker provides a division
that is to be regarded separately.

The signed portion of the message, is just that:  It's a *portion* of
the message that's signed.  It has to work that way, as the headers will
change in transit.  And, as we see on lists, footers can be added.

So a signed message doesn't authenticate the entire posting, just some
portion of it.  Unfortunately, the mail client doesn't indicate which
parts are verified by the signature.  Nor does mine indicate that only
some portion of the message is verified.  It's probably possible to
forward someone's signed message, add stuff below the signed content,
and fool people.

-- 
[tim@localhost ~]$ uname -rsvp
Linux 3.9.10-100.fc17.x86_64 #1 SMP Sun Jul 14 01:31:27 UTC 2013 x86_64 
(always current details of the computer that I'm writing this email on)

Boilerplate:  All mail to my mailbox is automatically deleted, there is
no point trying to privately email me, I only get to see the messages
posted to the mailing list.

I'd just like to say that vinyl record crackles and pops are far less
annoying than digigigigital mu-u-u-u-usic hiccicicicups and
yooo-u tu-be ... pauses.


___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: post-mortem: f24 boot fails; need help.

[Louis Lagendijk]

On Fri, 2017-06-09 at 02:51 +, William Mattison wrote:
> I did my weekly patches this afternoon, and this time the system
> booted up fine.  So I'm back to what caused the problems.
> * Motherboard battery?  Quite unlikely, but not 100%
> certain.  Battery replaced anyway.
> * Hard drive?  Somewhat unlikely.  Two 4-hour non-destructive disk
> checks found no issues.  System cleaned; cables dis- and re-
> connected; hard drive removed and put back in; no kinky cables
> seen.  Destructive testing and replacing the hard drive are not
> options for me at this time.  Circumstances suggest such would be
> over-kill.
> * Somehow caused by the "dnf upgrade"?  I can't assess this.  After
> the second failure (May 25), I backed up all user data, and then
> upgraded from f24 to f25.  I did not see any problems.  This
> afternoon's patches were f25; the failures were f24.  So I can no
> longer test whether f24 patching is at fault.  But if it were, I'd be
> surprised if I were the only person to be hit by it.  So my leaning
> is that it wasn't the patching that caused the problems.
> * Power supply?  Somewhat unlikely.  I know of no way to test
> this.  But Tim's analysis and other circumstances suggest it's not
> worth pursuing this possibility any further.
> 
> Two questions:
> 1. Are there any other theories I should consider?

As I said before: harddisk cable. I have seen SATA cables fail. Or
instead of the cable a bad contact repaired when you re-seated the
cable.
 
> 2. Should I submit a bugzilla?  (If yes, against what?)
No, this will not help if you don't know how to reproduce the fault.
especially as this quit possibly was a hardware error solved by re-
seating the cable..
> 
Louis
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

[389-users] Re: notes=A for filter with undefined attribute

[Clowser, Jeff]

Ideally, fix the client to change the filter to remove that.

If that's not possible, the other alternative is to fix it on the server side 
by forcing the DS to process this filter efficiently.

Something I found that seems to work is this:

- Define samaccountname in your schema
- index it as appropriate for the search your printer is doing (eq, substring, 
etc)

This should basically result in an empty index for samaccountname, and since 
you have nothing with this attribute, it will allow it to quickly process the 
fact that there are no results for that part of the filter and focus on the 
uid=someone part of the filter.  If you never populate anything with that 
attribute, I can't imagine it will add much/any work to the server to maintain 
that index or take much memory to cache it.  

Bit of a hack, but I had a similar problem with outlook searching on 
Displayname and this worked for that (displayname was already defined but I 
didn't populate it, just had to index it).





-Original Message-
From: albert@uwindsor.ca [mailto:albert@uwindsor.ca] 
Sent: Friday, June 9, 2017 9:28 AM
To: 389-users@lists.fedoraproject.org
Subject: [EXTERNAL] [389-users] notes=A for filter with undefined attribute 

Hi,

Xerox printer's LDAP connectivity's default search filter is 
(|(uid=someone)(samaccountname=someone)). samaccountname is not a defined 
attribute. This search filter will result notes=A, causing performance issue. 

Is there a way to avoid searching samaccountname=someone, since samaccountname 
is not a defined attribute. Thank you!
___
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send 
an email to 389-users-le...@lists.fedoraproject.org
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: notes=A for filter with undefined attribute

[Ludwig Krispenz]

On 06/09/2017 03:27 PM, albert@uwindsor.ca wrote:

Hi,

Xerox printer's LDAP connectivity's default search filter is 
(|(uid=someone)(samaccountname=someone)). samaccountname is not a defined 
attribute. This search filter will result notes=A, causing performance issue.

Is there a way to avoid searching samaccountname=someone, since samaccountname 
is not a defined attribute. Thank you!
no, I don't think so, and it should be easier to change the client to 
not use undefined attributes in searches instead of extending the server 
to handle all kinds of "..." requests.
If you want to bypass this, you can define the attribute and index it, 
it will be one quick index lookup for (samaccountname=someone)returning 
nothing and the results should be only based on (uid=someone)

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org


--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] notes=A for filter with undefined attribute

[albert . luo]

Hi,

Xerox printer's LDAP connectivity's default search filter is 
(|(uid=someone)(samaccountname=someone)). samaccountname is not a defined 
attribute. This search filter will result notes=A, causing performance issue. 

Is there a way to avoid searching samaccountname=someone, since samaccountname 
is not a defined attribute. Thank you!
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] v1.2 and v1.3 differences in return results for lookthroughlimit exceeding search

[albert . luo]

Hi,

In the following example, consumer replica v1.3 return err=11 with no entries. 
v1.2 return err=4, with the first 20 entries which is the size limit. Is this 
difference a change in the implementation or a configuration difference I am 
missing?

The look through limit is the default 5000. The tree has more than 50,000 
entries.

What is even more puzzling is that the master repica running v1.3 return the 
same result as v1.2. Only consumer replica v1.3 return err=11 with no entry.

Thank you very much.


389-Directory/1.3.5.10 B2017.115.1411, consumer replica

$ ldapsearch -x -H ldaps://ldapv1.3:636 -b "ou=People,dc=example,dc=com" -s one 
-a always -z 1000 "(objectClass=*)" "hasSubordinates" "objectClass"
# extended LDIF
#
# LDAPv3
# base 

Re: Using mrtg to monitor cable modem utilization

[Alex]

Hi,

On Wed, Jun 7, 2017 at 10:11 AM, Rick Stevens  wrote:

> I haven't edited the message so others can take a shot.
>
> We still use MRTG as a part of Nagios and Cacti in our monitoring
> systems but I haven't done any manual configs in a very long time. One
> common thing to keep in mind is that although NICs are generally
> specified in bits-per-second, SNMP (and consequently mrtg) use bytes-
> per-second. One gigabit IS 125,000,000 bytes (1,000,000,000 / 8 =
> 125,000,000).
>
> The MaxBytes option simply tells mrtg that values above this are to be
> ignored (ditto with AbsBytes). The primary idea is for mrtg to ignore
> nonsensical data which sometimes happens.
>
> I don't know if cfgmaker permits you to specify the "Thresh[Min|Max]*"
> options. That may still be a "manual, go hack the config yourself" step
> as it was back in the day (and a common reason people use Cacti (it
> allows you to set thresholds relatively easily through its GUI).

Thanks very much for the info. It's also been like a decade since I've
had to configure mrtg. Most of my concern comes from the large
disparity between the download (35mbit) and the upload (5mbit), and
the upload getting lost on the graph.

Ideas for other utilization graphing programs would be appreciated.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

[389-users] Re: Migration from OpenLDAP to 389 DS

[Blaz Kalan]

Hi, thank you all. Now I am a little further. 

My current tmp ldif file is as follows:

dn: cn=schema, cn=config
objectclass: top
objectclass: ldapSubentry
objectclass: subschema

dn: cn=itnetmanager, cn=schema, cn=config
objectclass: top
objectclass: ldapSubentry
objectclass: subschema

objectClasses: ( 1.3.6.1.4.1.1332.1000.30.1 NAME 'itPrepaidPinSub' DESC 
'IskratelprepaidPinSub' MUST ( itPrepaidPin ) )
attributeTypes: ( 1.3.6.1.4.1.1332.1000.10.1 NAME ('itPrepaidPin' 'ppin') DESC 
'IskratelprepaidPIN' EQUALITY numericStringMatch SUBSTR 
caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 SINGLE-VALUE )

When I try to import this file, I do not get any errors, and I can see schema 
and itnetmanager "folders" with ldap browser. But, I cannot see any entries 
(objectClasses or attributeTypes). What am I doing still wrong?

Thank you!
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

postgresql and firewald startup

[Jeandet Alexis]

Hello,

I have a server running F25 with postgresql and firewald configured.
On startup postgreslq always fail to start complaining about port 5432.
I did allow this port on the firewall, if I start manually postgresql
after it works.
So I did plot the startup sequence (systemd-analyse plot), I saw that
pgsql start after dbus.service but much before the firewall. Is there
something wrong with the default config of pgsql systemd unit?
Or more likely, what did I miss? mess :)?

boot graph:
https://ao.lpp.polytechnique.fr/s/7LdFkX5tlReNeqf

Best regards,
Alexis___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org