Fernando de Oliveira wrote:
> On 04-12-2011 16:45, DJ Lucas wrote:
>> On 12/04/2011 12:32 PM, Bruce Dubbs wrote:
>>> To make a fix, we could do something like:
>>>
>>> certdate=$( date -d "${date}" +%Y%m%d 2>/dev/null )
>>> if [ $? != 0 ]; then
>>> # skip it with continue
>>> # or remove it with rm -f "${cert}"
>>> fi
>> Yes, assuming that this is the 2038 bug, a continue here would be much
>> better, not more complex logic elsewhere. Thank you for catching that Bruce.
>>
>> -- DJ Lucas
>>
> Hi, DJ and Bruce,
>
> I am trying, but not sure yet.
>
> Attached, you find the log files.
>
> 1. old-ca-certificates* are obtained with the old script:
> ...
> if [ $( date -d "${date}" +%Y%m%d ) -lt ${today} ]; then
> echo "${cert} is expired! Removing..."
> rm -f "${cert}"
> fi
> done
I see the error here.
What we really want is:
certdate=$( date -d "${date}" +%Y%m%d 2>/dev/null )
# Test for date problems > 2038 on 32-bit systems
if [ $? = 0 ]; then continue; fi
if [ ${certdate} -lt ${today} ]; then
echo "${cert} is expired! Removing..."
rm -f "${cert}"
fi
This will remove expired certificates where they can be determined, but
leave them alone otherwise. In this case I think that's the right thing
to do. I'll note that this is a 32-bit system issue only. On an
x86_64, I get:
$ date -d "Dec 31 14:10:36 2040 GMT" +%Y%m%d
20401231
I'm not sure if date fails on an up-to-date 32-bit LFS system or not. I
don't have one handy to test.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
