Did you know that in USA, one of the way to support duck conservation is by buying duck stamps? I didn’t. Thanks to Last Week Tonight with John Oliver’s latest episode, now I do. Every year, a new duck stamp is released. To do so, there is an annual nationwide art contest to design duck stamp. And boy, it’s a serious business. By serious, I mean it has fierce competitions, rivalry and drama.

John and his team submitted 5 duck stamp designs. Funny enough, two were disqualified due to the art has numbers on it, and three were out without receiving any votes from the judges. As a revenge, John put these paintings on auction at bestduckingstamps.com. All the proceeds will be donated to Federal Duck Stamp program.

As of 1st Oct 2021 Singapore Time, I’m impressed with number of bids and value!

1. Leading the pack with 141 bids at $21,100.00 value is “Duck Hunt” by Eric Joyner.

   

2. Trailing behind the leader, with 89 bids at $17,500.00 value is “Duck Judges” by Bill Mayer.

   

3. On third position with 59 bids at $15,100.00 value is “Duck Hunting Hunters” by Josie Morway

   

4. On fourth position with 74 bids at $12,433.00 value is “Duck with a Pearl Earring” by Omar Rayyan

   

5. Last but not least, with 102 bids at $5,700.00 value is “Feuding Artist Handshake” by Roberto Parada

   

The full bids:

Today I notice that this blog’s disk usage is exceeding 50%.

So a maintenance is in order. One of the area that I can clean of is the logs. To check how much disk usage consumed by logs:

du -h /var/log

We can see which one consume the most:

104K    /var/log/apt                                                                                         
80K     /var/log/letsencrypt                                                                                 
4.0K    /var/log/apache2                                                                                     
32K     /var/log/mysql                                                                                       
80K     /var/log/unattended-upgrades                                                                         
44K     /var/log/exim4                                                                                       
4.0K    /var/log/samba                                                                                       
8.0K    /var/log/openvpn                                                                                     
1.1G    /var/log/journal/78571dd6ca7745fd883930edfbc1aec0                                                    
1.1G    /var/log/journal                                                                                     
880K    /var/log/nginx                                                                                       
1.2G    /var/log      

So the main culprit is /var/log/journal. But is it safe to remove the journal’s log? According to THIS, it’s perfectly safe.

With that in mind, let’s empty it out. But before deleting anything, let’s check the content:

ls /var/log/journal/78571dd6ca7745fd883930edfbc1aec0/

Looks like a number of journal files:

system.journal                                                                                               
system@e09f493f5d9543ccac3a01a18a5a7966-0000000000000001-0005c912944622d1.journal                            
system@e09f493f5d9543ccac3a01a18a5a7966-0000000000027cda-0005c9db59ac33c2.journal                            
system@e09f493f5d9543ccac3a01a18a5a7966-000000000004f9c8-0005ca3f9fdef072.journal                            
system@e09f493f5d9543ccac3a01a18a5a7966-0000000000078054-0005ca79a740fa97.journal                            
system@e09f493f5d9543ccac3a01a18a5a7966-00000000000a1c80-0005cb04b06080bc.journal                            
system@e09f493f5d9543ccac3a01a18a5a7966-00000000000ce097-0005cb2b4509171f.journal                            
system@e09f493f5d9543ccac3a01a18a5a7966-00000000000f8e58-0005cbabe81428d7.journal                            
system@e09f493f5d9543ccac3a01a18a5a7966-0000000000124d00-0005cbdc50807f36.journal                            
user-1000.journal

Let’s remove them all:

rm /var/log/journal/78571dd6ca7745fd883930edfbc1aec0/*.journal

Now verify the disk usage after:

du -h /var/log

It’s much less now:

104K    /var/log/apt                                                                                         
80K     /var/log/letsencrypt                                                                                 
4.0K    /var/log/apache2                                                                                     
32K     /var/log/mysql                                                                                       
80K     /var/log/unattended-upgrades                                                                         
44K     /var/log/exim4                                                                                       
4.0K    /var/log/samba                                                                                       
8.0K    /var/log/openvpn                                                                                     
4.0K    /var/log/journal/78571dd6ca7745fd883930edfbc1aec0                                                    
8.0K    /var/log/journal                                                                                     
884K    /var/log/nginx                                                                                       
62M     /var/log

Looks like we can clean further /var/log. Let’s find the offending files:

ls -l -S /var/log

And the culprits are:

-rw-rw----  1 root        utmp            18732672 Aug 31 02:22 btmp.1                                       
-rw-rw----  1 root        utmp            16121472 Sep 30 01:23 btmp                                         
-rw-r-----  1 syslog      adm             10247924 Sep 26 02:19 mail.log.1                                   
-rw-r-----  1 syslog      adm              9098913 Sep 27 02:20 auth.log.1                                   
-rw-r-----  1 syslog      adm              2289106 Sep 30 09:19 mail.log                                     
-rw-r-----  1 syslog      adm              1152534 Sep 13 02:20 auth.log.3.gz                                
-rw-r-----  1 syslog      adm              1069630 Sep 30 09:19 auth.log                                     
-rw-r-----  1 syslog      adm               972616 Sep  6 02:13 mail.log.4.gz                                
-rw-r-----  1 syslog      adm               744907 Sep 30 02:20 syslog.1                                     
-rw-r-----  1 syslog      adm               659046 Sep 12 02:20 mail.log.3.gz                                
-rw-r-----  1 syslog      adm               518091 Sep  5 02:20 auth.log.4.gz                                
-rw-r-----  1 syslog      adm               444680 Sep 20 02:19 mail.log.2.gz

We can use rm command to clean them.

That’s all friends! I hope it helps.

I recently find out that this blog’s internal pingback mechanism is broken. My post about volume balance in Windows 11, didn’t pingback to the earlier post for Windows 10. I doubt I disabled the pingback myself. Because to what I know, internal pingback is good for SEO.

So I start digging around for possible cause. After a while, my suspicion is pointing at this plugin Remove XMLRPC Pingback Ping. As a test, I deactivated this plugin and proceeded to write my last post. After published my last post, the findings is confirming my suspicion. My last post which is about Telerik’s RadEditor, managed to pingback to my other post about WebComponentsIcons.

Now the tricky part is how to resend the missing pingbacks of previous posts?

How To Manually Send Pingbacks

With Google’s help, I managed to find a clue on how to manually send pingback. First, let’s create an XML file called pingback.xml:

<?xml version="1.0" encoding="iso-8859-1"?>
<methodCall>
<methodName>pingback.ping</methodName>
<params>
 <param>
  <value>
   <!-- source -->
   <string>_URL_SOURCE_REFERRING_TO_</string>
  </value>
 </param>
 <param>
  <value>
   <!-- target -->
   <string>_URL_DEST_REFERRED_</string>
  </value>
 </param>
</params>
</methodCall>

Specific to my case:

• _URL_SOURCE_REFERRING_TO_ is https://sodeve.net/2021/09/how-to-adjust-audio-balance-left-right-in-windows-11/
• _URL_DEST_REFERRED_ is https://sodeve.net/2015/09/how-to-adjust-audio-balance-left-right-in-windows-10/

The next step requires curl to be installed in your system. Once installed and accessible from console/command-line, we can execute below code in console/command-line:

curl -X POST -d @pingback.xml http://your-site.com/xmlrpc.php

For my case, it’s:

curl -X POST -d @pingback.xml https://sodeve.net/xmlrpc.php

If the post is successful, the response should be similar to this:

<?xml version="1.0" encoding="UTF-8"?>
<methodResponse>
  <params>
    <param>
      <value>
      <string>Pingback from https://sodeve.net/2021/09/how-to-adjust-audio-balance-left-right-in-windows-11/ to https://sodeve.net/2015/09/how-to-adjust-audio-balance-left-right-in-windows-10/ registered. Keep the web talking! :-)</string>
      </value>
    </param>
  </params>
</methodResponse>

Otherwise, we should able to find clue in the faultCode/faultString (specific to below response, I did make a mistake of putting the same url in source and destination 😀 ):

<?xml version="1.0" encoding="UTF-8"?>
<methodResponse>
  <fault>
    <value>
      <struct>
        <member>
          <name>faultCode</name>
          <value><int>0</int></value>
        </member>
        <member>
          <name>faultString</name>
          <value><string></string></value>
        </member>
      </struct>
    </value>
  </fault>
</methodResponse>

That’s about it, I hope it helps. Cheers!