Fixing Page Order When Cropping Two-Column Persian PDFs

2026-06-20T00:00:00+00:00

Fixing Page Order When Cropping Two-Column Persian PDFs</h1>

Some e-book readers render two-column scanned PDFs poorly. Splitting each spread into individual pages fixes readability — but for Persian (right-to-left) books, a naive split leaves the pages in the wrong order.</p>

Credit to Jadi's original post</a> for the convert</code>-based approach — this uses mutool</code> instead, which handles the splitting in one step.</p> </blockquote>


1. Split Each Two-Column Page Into Two Single Pages</h2>
sudo</span> apt install mupdf-tools</span></span></code></pre>mutool</span> poster -x</span> 2</span> haj_sayah.pdf output.pdf</span></span></code></pre>
What this does:</strong> Splits each two-column spread into two separate single-column pages.</p>

2. Fix the Resulting Page Order</h2>
Why it breaks:</strong> Persian is written right-to-left, so pages in a Persian book are ordered in
reverse relative to a left-to-right book. mutool poster</code> splits pages assuming left-to-right order,
which works fine for English books but scrambles the order for Persian ones.</p>
The fix:</strong> Swap each even page with the odd page next to it.</p>
sudo</span> apt install pdftk</span></span></code></pre>pdftk</span> output.pdf shuffle even odd output haj_sayyah_.pdf</span></span></code></pre>

3. Restore the Original Cover</h2>
The shuffle step also reorders the cover. Swap it back from the original file:</p>
pdftk</span> A=haj_sayyah_.pdf B=haj_sayah.pdf cat B1 A3-end output out1.pdf</span></span></code></pre>

Result</h2>
out1.pdf</code> is the final, correctly-ordered, single-column file — readable page by page on any e-reader.</p>
Step</th> Command</th> Purpose</th></tr></thead>

1</td> mutool poster -x 2</code></td> Split columns</td></tr>
2</td> pdftk shuffle even odd</code></td> Fix RTL order</td></tr>
3</td> pdftk cat B1 A3-end</code></td> Restore cover</td></tr>
</tbody></table>


Networking Lab with MikroTik RouterOS
2026-06-20T00:00:00+00:00
Networking Lab with MikroTik RouterOS</h1>
MikroTik RouterOS is a good, low-cost way to get hands-on with networking concepts without buying
physical hardware. This post covers running it as a VM, exposing its WebUI and SSH through a
reverse proxy, and connecting to it from the host machine.</p>
Prerequisites</h2>
Component</th> Version</th></tr></thead>

Host OS</td> Debian GNU/Linux (stable)</td></tr>
Hypervisor</td> VirtualBox</td></tr>
RouterOS</td> MikroTik x86 ISO</td></tr>
</tbody></table>
Download the ISO from the MikroTik website</a>.</p>

1. Create the VM</h2>
In VirtualBox, create a new VM with type Other/Unknown (64-bit)</strong>.</p>

Enable VT-x</strong> in system settings</li>
Attach mikrotik-7.10.1.iso</code> to the CD drive</li>
Boot and press i</code> then Enter</code> to install</li>
</ul>

2. First Boot</h2>
Log in to the console:</p>
user: admin</span></span>
password: (empty)</span></span></code></pre>
Request an IP from the internal DHCP server:</p>
/ip</span> dhcp-client add interface=ether1 disabled=no</span></span>
/ip</span> address print</span></span></code></pre>
Expected output:</p>
[admin@MikroTik] > ip/address/print</span></span>
Flags: D - DYNAMIC</span></span>
Columns: ADDRESS, NETWORK, INTERFACE</span></span>
#   ADDRESS           NETWORK      INTERFACE</span></span>
0 D 10.0.2.15/24      10.0.2.0     ether1</span></span></code></pre>

3. Port Forwarding</h2>
VirtualBox's NAT network can forward ports from the host to the guest.</p>
Service</th> Host IP</th> Host Port</th> Guest IP</th> Guest Port</th></tr></thead>

SSH</td> 127.0.0.1</td> 9090</td> 10.0.2.15</td> 22</td></tr>
WebUI</td> 127.0.0.1</td> 8080</td> 10.0.2.15</td> 80</td></tr>
</tbody></table>
Traffic hitting localhost:9090</code> and localhost:8080</code> now redirects to the guest.</p>

4. Access Methods</h2>
Option A: Nginx Reverse Proxy</h3>
Create /etc/nginx/conf.d/local_proxy.conf</code>:</p>
server {</span></span>
    listen 80;</span></span>
    server_name webfig.ir;</span></span>
</span>
    location / {</span></span>
        proxy_pass http://127.0.0.1:8080/;</span></span>
    }</span></span>
}</span></span></code></pre>sudo</span> nginx -t</span></span>
sudo</span> systemctl restart nginx</span></span></code></pre>
Add to /etc/hosts</code>:</p>
127.0.0.1       webfig.ir</span></span></code></pre>
Now http://webfig.ir</code> reaches the MikroTik WebUI.</p>
Option B: SimpleProxy (No Nginx)</h3>
sudo</span> apt install simpleproxy</span></span>
sudo</span> simpleproxy -L webfig.ir:80 -R 127.0.0.1:8080</span></span></code></pre>Option C: SSH</h3>
ssh</span> -p</span> 9090</span> admin@127.0.0.1</span></span></code></pre>
Add to ~/.ssh/config</code> for convenience:</p>
Host mikrotik</span></span>
    HostName 127.0.0.1</span></span>
    User admin</span></span>
    Port 9090</span></span>
    KexAlgorithms diffie-hellman-group-exchange-sha256</span></span></code></pre>
Then just:</p>
ssh</span> mikrotik</span></span></code></pre>Option D: Winbox via Wine</h3>
sudo</span> apt install wine</span></span>
wine</span> winbox64.exe</span></span></code></pre>

References</h2>

AskUbuntu: Port forwarding</a></li>
SimpleProxy manpage</a></li>
Baeldung: Mapping hostnames/ports</a></li>
SuperUser: MikroTik SSH</a></li>
</ul>


Run Multiple Debian VMs with Vagrant and VirtualBox
2026-06-20T00:00:00+00:00
Run Multiple Debian VMs with Vagrant and VirtualBox</h1>
This guide sets up 3 Debian virtual machines</strong> with working vagrant ssh</code>, using VirtualBox</strong>
as the provider. The box choice and shell provisioner below are what makes SSH work reliably on
Debian — both trip people up if skipped.</p>

1. Vagrantfile</h2>
Save this as Vagrantfile</code> in your project directory. It defines the 3 VMs in a loop rather than
repeating the same block three times:</p>
Vagrant</span>.</span>configure</span>(</span>"2"</span>)</span> do</span> |</span>config</span>|</span></span>
  # Only this Debian box works reliably with Vagrant SSH + VirtualBox</span></span>
  config</span>.</span>vm</span>.</span>box</span> =</span> "generic/debian12"</span></span>
</span>
  (</span>1</span>..</span>3</span>).</span>each</span> do</span> |</span>i</span>|</span></span>
    config</span>.</span>vm</span>.</span>define</span> "debian</span>#{</span>i</span>}</span>"</span> do</span> |</span>vm</span>|</span></span>
      vm</span>.</span>vm</span>.</span>hostname</span> =</span> "debian</span>#{</span>i</span>}</span>"</span></span>
      vm</span>.</span>vm</span>.</span>network</span> "private_network"</span>,</span> ip</span>:</span> "192.168.56.</span>#{</span>149</span> +</span> i</span>}</span>"</span></span>
</span>
      vm</span>.</span>vm</span>.</span>provider</span> "virtualbox"</span> do</span> |</span>vb</span>|</span></span>
        vb</span>.</span>memory</span> =</span> 1024</span></span>
        vb</span>.</span>cpus</span> =</span> 1</span></span>
      end</span></span>
</span>
      # Required to be able to SSH into the guest machines</span></span>
      vm</span>.</span>vm</span>.</span>provision</span> "shell"</span>,</span> inline</span>:</span> <<-SHELL</span></span>
        chmod</span> 700</span> /home/vagrant/.ssh</span></span>
        chmod</span> 600</span> /home/vagrant/.ssh/authorized_keys</span></span>
        chown</span> -R vagrant:vagrant /home/vagrant/.ssh</span></span>
      SHELL</span></span>
    end</span></span>
  end</span></span>
end</span></span></code></pre>
This produces debian1</code>, debian2</code>, debian3</code> on 192.168.56.150</code>, .151</code>, .152</code> respectively —
same result as writing out three separate blocks, less to maintain.</p>

2. Usage</h2>
Destroy any previous VMs and clear old state:</strong></p>
vagrant</span> destroy -f</span></span>
rm</span> -rf .vagrant</span></span></code></pre>
Start all 3 VMs:</strong></p>
vagrant</span> up</span></span></code></pre>
SSH into each VM:</strong></p>
vagrant</span> ssh debian1</span></span>
vagrant</span> ssh debian2</span></span>
vagrant</span> ssh debian3</span></span></code></pre>
Stop all VMs:</strong></p>
vagrant</span> halt</span></span></code></pre>
Remove all VMs permanently:</strong></p>
vagrant</span> destroy -f</span></span></code></pre>

3. Notes</h2>

Use generic/debian12</code></strong> — other boxes (like debian/bookworm64</code>) can leave authorized_keys</code>
empty and break SSH.</li>
The shell provisioner block</strong> is required on Debian to set correct SSH permissions; without it,
vagrant ssh</code> fails.</li>
Each VM uses a private network</strong> for predictable IPs.</li>
Tested with VirtualBox 7.x</strong> and the Vagrant AppImage on Linux, macOS, and Windows.</li>
</ul>


Kubernetes Migration Lab: VMs to EKS
2025-11-10T00:00:00+00:00
This is a personal lab writeup, not a claimed production project.</strong> I set it up to practice the
workflow and tooling involved in a VM-to-Kubernetes migration, using a small sample service rather
than a real company's infrastructure.</p>
Goal</h2>
Get hands-on with the pieces that make up a typical Kubernetes migration, end to end:</p>

Provision an EKS cluster with Terraform</strong> instead of clicking through the AWS console.</li>
Package the service with Helm</strong> so config is versioned and repeatable.</li>
Wire up ArgoCD</strong> for GitOps-style deployment instead of manual kubectl apply</code>.</li>
Add Prometheus</strong> and Grafana</strong> for cluster and application metrics.</li>
Run the pipeline through GitHub Actions</strong> so image builds and Helm releases are automated.</li>
</ol>
What I practiced</h2>

Writing Terraform modules for VPC, subnets, and an EKS control plane, and tearing it down cleanly
afterward (terraform destroy</code>) to avoid runaway AWS costs on a personal account.</li>
Structuring a Helm chart with separate values</code> files per environment, and using helm diff</code> to
review changes before they hit the cluster.</li>
Pointing ArgoCD at a Git repo and watching it reconcile drift instead of trusting manual deploys.</li>
Setting resource requests/limits and a basic HorizontalPodAutoscaler, then load-testing to see
when pods actually scaled.</li>
Hooking up the kube-prometheus-stack and building a couple of Grafana dashboards for pod restarts
and request latency.</li>
</ul>
What I'd still want to test on a real workload</h2>

Zero-downtime cutover strategies (blue/green vs. canary) under real traffic, not synthetic load.</li>
Database migration alongside the app — stateful services are the part this lab skipped entirely.</li>
Cost comparison against the VM baseline with real numbers, not estimates.</li>
</ul>
Notes for next time</h2>
Terraform state management got messy once I started iterating quickly — next time I'd set up remote
state with locking from the start instead of retrofitting it. ArgoCD's health checks also needed
tuning for a custom readiness probe; the defaults reported "healthy" before the app was actually
ready to take traffic.</p>

EsmaeelE - Free Software enthusiast - DevOps

Fixing Page Order When Cropping Two-Column Persian PDFs

Networking Lab with MikroTik RouterOS

Networking Lab with MikroTik RouterOS</h1> MikroTik RouterOS is a good, low-cost way to get hands-on with networking concepts without buying physical hardware. This post covers running it as a VM, exposing its WebUI and SSH through a reverse proxy, and connecting to it from the host machine.</p>

4. Access Methods</h2>

Run Multiple Debian VMs with Vagrant and VirtualBox

Kubernetes Migration Lab: VMs to EKS

Networking Lab with MikroTik RouterOS</h1>
MikroTik RouterOS is a good, low-cost way to get hands-on with networking concepts without buying physical hardware. This post covers running it as a VM, exposing its WebUI and SSH through a reverse proxy, and connecting to it from the host machine.</p>