Re: [rsyslog] librdkafka packages in v8-stable/epel-7/x86_64/RPMS

[Derek DiFilippo]

Hi Florian,

As of now there are 8 packages in the rsyslog repo providing the
librdkafka++.so.1 dependency.
(and one package in epel, that's the last in the list below)

thanks,
-Derek.

**

$ yum whatprovides --disablerepo=epel /usr/lib64/librdkafka++.so.1
Loaded plugins: langpacks, product-id, search-disabled-repos,
subscription-manager
adiscon-librdkafka1-0.8.5-1.x86_64 : The Apache Kafka C library
Repo: rsyslog_v8
Matched from:
Filename: /usr/lib64/librdkafka++.so.1

adiscon-librdkafka1-0.8.6-1.x86_64 : The Apache Kafka C library
Repo: rsyslog_v8
Matched from:
Filename: /usr/lib64/librdkafka++.so.1

adisconbuild-librdkafka1-0.9.5-1.x86_64 : The Apache Kafka C library
Repo: rsyslog_v8
Matched from:
Filename: /usr/lib64/librdkafka++.so.1

adisconbuild-librdkafka1-0.11.0-1.x86_64 : The Apache Kafka C library
Repo: rsyslog_v8
Matched from:
Filename: /usr/lib64/librdkafka++.so.1

adisconbuild-librdkafka1-0.11.0-2.x86_64 : The Apache Kafka C library
Repo: rsyslog_v8
Matched from:
Filename: /usr/lib64/librdkafka++.so.1

adisconbuild-librdkafka1-0.11.1-1.x86_64 : The Apache Kafka C library
Repo: rsyslog_v8
Matched from:
Filename: /usr/lib64/librdkafka++.so.1

adisconbuild-librdkafka1-0.11.3-1.x86_64 : The Apache Kafka C library
Repo: rsyslog_v8
Matched from:
Filename: /usr/lib64/librdkafka++.so.1

adisconbuild-librdkafka1-0.11.4-1.x86_64 : The Apache Kafka C library
Repo: rsyslog_v8
Matched from:
Filename: /usr/lib64/librdkafka++.so.1

librdkafka-0.11.3-1.el7.x86_64 : The Apache Kafka C library
Repo: @epel
Matched from:
Filename: /usr/lib64/librdkafka++.so.1


On Fri, Apr 20, 2018 at 11:53 AM, Derek DiFilippo  wrote:

> Hi Florian:
>
> Thanks for removing that package.
>
> So you know, there are still others in the rsyslog repo that satisfy the
> same dependency
> We still see a conflict but now with one of the adiscon-librdkafka
> packages.
>
> The conflict used to be this:
>
> Transaction check error:
>   file /usr/lib64/librdkafka++.so.1 conflicts between attempted installs of 
> librdkafka1-0.8.5-0.x86_64 and librdkafka-0.11.3-1.el7.x86_64
>   file /usr/lib64/librdkafka.so.1 conflicts between attempted installs of 
> librdkafka1-0.8.5-0.x86_64 and librdkafka-0.11.3-1.el7.x86_64
>
> and now it's this:
>
> Transaction check error:
>   file /usr/lib64/librdkafka++.so.1 conflicts between attempted installs of 
> adiscon-librdkafka1-0.8.6-1.x86_64 and librdkafka-0.11.3-1.el7.x86_64
>   file /usr/lib64/librdkafka.so.1 conflicts between attempted installs of 
> adiscon-librdkafka1-0.8.6-1.x86_64 and librdkafka-0.11.3-1.el7.x86_64
>
>
> I'll be that the other packages could be removed as well. Or if necessary
> put into a separate internal repository you can use for builds.
>
> thanks,
> -D.
>
> On Fri, Apr 20, 2018 at 12:57 AM, Florian Riedl 
> wrote:
>
>> Derek, quick update.
>>
>> I removed the librdkafka1 RPM from the repository for EL6 and EL7.
>> Since this exact RPM was not used by rsyslog anyway, it seems safe to
>> let it go.
>>
>> I updated the repository accordingly, did a quick install test on my
>> lab machine and yum couldn't find it anymore, so I assume this worked
>> out right away.
>>
>> Florian
>>
>> 2018-04-20 7:46 GMT+02:00 Rainer Gerhards :
>> > Derek,
>> >
>> > thanks for the info. This is very useful for me. Obviously I
>> > misunderstood how RPMs work in that regard.
>> >
>> > As as far as librdkafka1 is involved, the root problem is clear. I
>> > probably need to review now if we build non-rsyslog components
>> > somewhere else which may also cause issues.
>> >
>> > I think we probably also can have conflicts in regard to support
>> > libraries, like libfastjson. This is more or less inevitable. The
>> > rsyslog package obviously also conflicts with OS packages. Maybe a
>> > warning might be due that folks should not add our repositories if
>> > they also use "this and that" component (e.g. another application that
>> > requires a different libfastjson)?
>> >
>> > David: what do you think?
>> >
>> > Rainer
>> > PS: I never was a big fan of doing packaging but it seems to be
>> > important enough to justify the troubles associated with it.
>> >
>> > 2018-04-20 0:36 GMT+02:00 Derek DiFilippo :
>> >> It's done by file name, not package name.
>> >>
>> >> To double check I made a simple rpm that builds and packages two of the
>> >> examples from the librdkafka repo.
>> >>
>> >> There's no mention of rsyslog or librdkafka packages anywhere. The
>> >> dependencies are driven by the files.
>> >>
>> >> Two examples below. In the second I disable epel and it finds the
>> >> librdkafka1 in the rsyslog repository.
>> >>
>> >> [ec2-user@ip-172-31-18-125 ~]$ sudo yum install
>> >> kafka-conflict-1.1.0-Linux.rpm
>> >> Loaded plugins: amazon-id, rhui-lb, search-disabled-repos
>> >> Examining 

Re: [rsyslog] librdkafka packages in v8-stable/epel-7/x86_64/RPMS

[Derek DiFilippo]

Hi Florian:

Thanks for removing that package.

So you know, there are still others in the rsyslog repo that satisfy the
same dependency
We still see a conflict but now with one of the adiscon-librdkafka packages.

The conflict used to be this:

Transaction check error:
  file /usr/lib64/librdkafka++.so.1 conflicts between attempted
installs of librdkafka1-0.8.5-0.x86_64 and
librdkafka-0.11.3-1.el7.x86_64
  file /usr/lib64/librdkafka.so.1 conflicts between attempted installs
of librdkafka1-0.8.5-0.x86_64 and librdkafka-0.11.3-1.el7.x86_64

and now it's this:

Transaction check error:
  file /usr/lib64/librdkafka++.so.1 conflicts between attempted
installs of adiscon-librdkafka1-0.8.6-1.x86_64 and
librdkafka-0.11.3-1.el7.x86_64
  file /usr/lib64/librdkafka.so.1 conflicts between attempted installs
of adiscon-librdkafka1-0.8.6-1.x86_64 and
librdkafka-0.11.3-1.el7.x86_64


I'll be that the other packages could be removed as well. Or if necessary
put into a separate internal repository you can use for builds.

thanks,
-D.

On Fri, Apr 20, 2018 at 12:57 AM, Florian Riedl  wrote:

> Derek, quick update.
>
> I removed the librdkafka1 RPM from the repository for EL6 and EL7.
> Since this exact RPM was not used by rsyslog anyway, it seems safe to
> let it go.
>
> I updated the repository accordingly, did a quick install test on my
> lab machine and yum couldn't find it anymore, so I assume this worked
> out right away.
>
> Florian
>
> 2018-04-20 7:46 GMT+02:00 Rainer Gerhards :
> > Derek,
> >
> > thanks for the info. This is very useful for me. Obviously I
> > misunderstood how RPMs work in that regard.
> >
> > As as far as librdkafka1 is involved, the root problem is clear. I
> > probably need to review now if we build non-rsyslog components
> > somewhere else which may also cause issues.
> >
> > I think we probably also can have conflicts in regard to support
> > libraries, like libfastjson. This is more or less inevitable. The
> > rsyslog package obviously also conflicts with OS packages. Maybe a
> > warning might be due that folks should not add our repositories if
> > they also use "this and that" component (e.g. another application that
> > requires a different libfastjson)?
> >
> > David: what do you think?
> >
> > Rainer
> > PS: I never was a big fan of doing packaging but it seems to be
> > important enough to justify the troubles associated with it.
> >
> > 2018-04-20 0:36 GMT+02:00 Derek DiFilippo :
> >> It's done by file name, not package name.
> >>
> >> To double check I made a simple rpm that builds and packages two of the
> >> examples from the librdkafka repo.
> >>
> >> There's no mention of rsyslog or librdkafka packages anywhere. The
> >> dependencies are driven by the files.
> >>
> >> Two examples below. In the second I disable epel and it finds the
> >> librdkafka1 in the rsyslog repository.
> >>
> >> [ec2-user@ip-172-31-18-125 ~]$ sudo yum install
> >> kafka-conflict-1.1.0-Linux.rpm
> >> Loaded plugins: amazon-id, rhui-lb, search-disabled-repos
> >> Examining kafka-conflict-1.1.0-Linux.rpm: kafka-conflict-1.1.0-1.x86_64
> >> Marking kafka-conflict-1.1.0-Linux.rpm to be installed
> >> Resolving Dependencies
> >> --> Running transaction check
> >> ---> Package kafka-conflict.x86_64 0:1.1.0-1 will be installed
> >> --> Processing Dependency: librdkafka++.so.1()(64bit) for package:
> >> kafka-conflict-1.1.0-1.x86_64
> >> --> Running transaction check
> >> ---> Package librdkafka.x86_64 0:0.11.3-1.el7 will be installed
> >> --> Finished Dependency Resolution
> >>
> >> Dependencies Resolved
> >>
> >> 
> 
> ==
> >>  Package  Arch Version
> >>   Repository Size
> >> 
> 
> ==
> >> Installing:
> >>  kafka-conflict   x86_64   1.1.0-1
> >>   /kafka-conflict-1.1.0-Linux92 k
> >> Installing for dependencies:
> >>  librdkafka   x86_64   0.11.3-1.el7
> >>epel  326 k
> >>
> >> Transaction Summary
> >> 
> 
> ==
> >> Install  1 Package (+1 Dependent package)
> >>
> >> Total size: 418 k
> >> Installed size: 1.1 M
> >>
> >> 
> >> 
> >>
> >> [ec2-user@ip-172-31-18-125 ~]$ sudo yum install --disablerepo=epel
> >> kafka-conflict-1.1.0-Linux.rpm
> >> Loaded plugins: amazon-id, rhui-lb, search-disabled-repos
> >> Examining kafka-conflict-1.1.0-Linux.rpm: 

Re: [rsyslog] TZ variable

[Marco]

Il 20/04/2018 09:36, Marco ha scritto:


[Service]
Environment="TZ='Europe/Rome'"



Ops, I'm sorry. I must set

[Service]
Environment="TZ=Europe/Rome"


Now it works :)

Have a nice day

  Marco
___
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of 
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE 
THAT.

Re: [rsyslog] Avoid invld PRI and force a valid PRI

[Rainer Gerhards]

which rsyslog version do you have? I think current ones have an
automatic replace capability, but I am not 100% sure.

Rainer

2018-04-20 10:32 GMT+02:00 Simon Lundström :
> Hey all!
>
> We have some devices which can't be easily fixed which uses an
> invalid/incorrect syslog PRI. rsyslogd sets these as  e.g.:
> 2018-04-20T10:19:49.973793+02:00 central.syslog.server
> 2018-04-20T10:19:49+02:00 server.which.syslogged  <198>Apr 20
> 10:19:49 server.which.syslogged program: message
>
> Is it possible for rsyslog just to set a valid PRI instead of "reporting"
> it.
> Can "central.syslog.server" do it? Or must "server.which.syslogged" do it?
>
> Thanks!
>
> BR,
> - Simon
> ___
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/
> What's up with rsyslog? Follow https://twitter.com/rgerhards
> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
> sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T
> LIKE THAT.
___
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of 
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE 
THAT.

[rsyslog] Avoid invld PRI and force a valid PRI

[Simon Lundström]

Hey all!

We have some devices which can't be easily fixed which uses an 
invalid/incorrect syslog PRI. rsyslogd sets these as  e.g.:

2018-04-20T10:19:49.973793+02:00 central.syslog.server  
2018-04-20T10:19:49+02:00 server.which.syslogged  <198>Apr 20 10:19:49 
server.which.syslogged program: message

Is it possible for rsyslog just to set a valid PRI instead of 
"reporting" it.
Can "central.syslog.server" do it? Or must "server.which.syslogged" do 
it?


Thanks!

BR,
- Simon
___
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of 
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE 
THAT.

Re: [rsyslog] librdkafka packages in v8-stable/epel-7/x86_64/RPMS

[Florian Riedl]

Derek, quick update.

I removed the librdkafka1 RPM from the repository for EL6 and EL7.
Since this exact RPM was not used by rsyslog anyway, it seems safe to
let it go.

I updated the repository accordingly, did a quick install test on my
lab machine and yum couldn't find it anymore, so I assume this worked
out right away.

Florian

2018-04-20 7:46 GMT+02:00 Rainer Gerhards :
> Derek,
>
> thanks for the info. This is very useful for me. Obviously I
> misunderstood how RPMs work in that regard.
>
> As as far as librdkafka1 is involved, the root problem is clear. I
> probably need to review now if we build non-rsyslog components
> somewhere else which may also cause issues.
>
> I think we probably also can have conflicts in regard to support
> libraries, like libfastjson. This is more or less inevitable. The
> rsyslog package obviously also conflicts with OS packages. Maybe a
> warning might be due that folks should not add our repositories if
> they also use "this and that" component (e.g. another application that
> requires a different libfastjson)?
>
> David: what do you think?
>
> Rainer
> PS: I never was a big fan of doing packaging but it seems to be
> important enough to justify the troubles associated with it.
>
> 2018-04-20 0:36 GMT+02:00 Derek DiFilippo :
>> It's done by file name, not package name.
>>
>> To double check I made a simple rpm that builds and packages two of the
>> examples from the librdkafka repo.
>>
>> There's no mention of rsyslog or librdkafka packages anywhere. The
>> dependencies are driven by the files.
>>
>> Two examples below. In the second I disable epel and it finds the
>> librdkafka1 in the rsyslog repository.
>>
>> [ec2-user@ip-172-31-18-125 ~]$ sudo yum install
>> kafka-conflict-1.1.0-Linux.rpm
>> Loaded plugins: amazon-id, rhui-lb, search-disabled-repos
>> Examining kafka-conflict-1.1.0-Linux.rpm: kafka-conflict-1.1.0-1.x86_64
>> Marking kafka-conflict-1.1.0-Linux.rpm to be installed
>> Resolving Dependencies
>> --> Running transaction check
>> ---> Package kafka-conflict.x86_64 0:1.1.0-1 will be installed
>> --> Processing Dependency: librdkafka++.so.1()(64bit) for package:
>> kafka-conflict-1.1.0-1.x86_64
>> --> Running transaction check
>> ---> Package librdkafka.x86_64 0:0.11.3-1.el7 will be installed
>> --> Finished Dependency Resolution
>>
>> Dependencies Resolved
>>
>> ==
>>  Package  Arch Version
>>   Repository Size
>> ==
>> Installing:
>>  kafka-conflict   x86_64   1.1.0-1
>>   /kafka-conflict-1.1.0-Linux92 k
>> Installing for dependencies:
>>  librdkafka   x86_64   0.11.3-1.el7
>>epel  326 k
>>
>> Transaction Summary
>> ==
>> Install  1 Package (+1 Dependent package)
>>
>> Total size: 418 k
>> Installed size: 1.1 M
>>
>> 
>> 
>>
>> [ec2-user@ip-172-31-18-125 ~]$ sudo yum install --disablerepo=epel
>> kafka-conflict-1.1.0-Linux.rpm
>> Loaded plugins: amazon-id, rhui-lb, search-disabled-repos
>> Examining kafka-conflict-1.1.0-Linux.rpm: kafka-conflict-1.1.0-1.x86_64
>> Marking kafka-conflict-1.1.0-Linux.rpm to be installed
>> Resolving Dependencies
>> --> Running transaction check
>> ---> Package kafka-conflict.x86_64 0:1.1.0-1 will be installed
>> --> Processing Dependency: librdkafka++.so.1()(64bit) for package:
>> kafka-conflict-1.1.0-1.x86_64
>> --> Running transaction check
>> ---> Package librdkafka1.x86_64 0:0.8.5-0 will be installed
>> --> Finished Dependency Resolution
>>
>> Dependencies Resolved
>>
>> ==
>>  Package   Arch  Version
>>  Repository  Size
>> ==
>> Installing:
>>  kafka-conflictx86_641.1.0-1
>>  /kafka-conflict-1.1.0-Linux 92 k
>> Installing for dependencies:
>>  librdkafka1   x86_640.8.5-0
>>  rsyslog_v8 100 k
>>
>> Transaction Summary
>> 

[rsyslog] TZ variable

[Marco]

Hello,

 I use Rsyslog 8.34 with RH EL 7.5 and I would ask help about timezone.

When rsyslog starts, a warning says

"2018-04-20T09:02:02.567509+02:00 host rsyslogd[6283]: environment 
variable TZ is not set, auto correcting this to TZ=/etc/localtime

[v8.34.0 try http://www.rsyslog.com/e/2442 ]"

and all is working fine.


But I tried to follow the suggest to set the TZ variable.

I run tzselect, and I set in systemd start script:

[Service]
Environment="TZ='Europe/Rome'"


I restarted Rsyslog and the warning disappeared.

But now the timezone is not honored:

2018-04-20T07:10:55.341708+00:00 maillog systemd[1]: Starting System 
Logging Service...
2018-04-20T07:10:55.398861+00:00 maillog rsyslogd[6229]: [origin 
software="rsyslogd" swVersion="8.34.0" x-pid="6229" x-info="http://www.

rsyslog.com"] start



Note that even if TZ is not set, timedatectl reports the expected timezone:

# timedatectl
  Local time: Fri 2018-04-20 09:25:29 CEST
  Universal time: Fri 2018-04-20 07:25:29 UTC
RTC time: Fri 2018-04-20 07:25:29
   Time zone: Europe/Rome (CEST, +0200)
 NTP enabled: yes
NTP synchronized: yes
 RTC in local TZ: no
  DST active: yes
 Last DST change: DST began at
  Sun 2018-03-25 01:59:59 CET
  Sun 2018-03-25 03:00:00 CEST
 Next DST change: DST ends (the clock jumps one hour backwards) at
  Sun 2018-10-28 02:59:59 CEST
  Sun 2018-10-28 02:00:00 CET


I set TZ variable only for the rsyslog warn message.

Do you have any hint about how to deal with TZ env variable and rsyslog?

Many thanks
Kind Regards
Marco
___
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of 
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE 
THAT.