avi9526's questions

I was playing with my LVM thin installation. Created multiple snapshots, merged them with origin many times. At some point in the output of lvs -a command oldest snapshots lost its origin. In the output of more detailed command lvs -a -o time,name,origin,lv_role this snapshots are now have lv_role as public (while snapshots have roles public,snapshot,thinsnapshot). merge is now not possible with error is not a mergeable logical volume. Now I have multiple questions:

1. is this orphaned snapshots are proper volumes or they are corrupted?
2. why does this happen? (I was merging some middle in terms of creation time snapshots with their origin and then recreating them)
3. can I manually remove origin from a snapshot to make it separated volume?
4. is there a way back for this volumes to became snapshots with equal blocks of data being linked to origin again to preserve space?

Update. Test script.

initial config with name of VG and pool that should exist:

VG=vg
Pool="${VG}"/pool0
Test_volume="test"

create test LV and make it random

lvcreate -V10M -T "${Pool}" -n "${Test_volume}"

lvchange -ay -Ky "${VG}"/"${Test_volume}"

dd if=/dev/urandom of="/dev/${VG}/${Test_volume}"
lvcreate -n "${Test_volume}_snap_0" --snapshot "${VG}"/"${Test_volume}"
lvchange -ay -Ky "${VG}"/"${Test_volume}_snap_0"

dd if=/dev/urandom of="/dev/${VG}/${Test_volume}"
lvcreate -n "${Test_volume}_snap_1" --snapshot "${VG}"/"${Test_volume}"
lvchange -ay -Ky "${VG}"/"${Test_volume}_snap_1"

dd if=/dev/urandom of="/dev/${VG}/${Test_volume}"
lvcreate -n "${Test_volume}_snap_2" --snapshot "${VG}"/"${Test_volume}"
lvchange -ay -Ky "${VG}"/"${Test_volume}_snap_2"

dd if=/dev/urandom of="/dev/${VG}/${Test_volume}"
lvcreate -n "${Test_volume}_snap_3" --snapshot "${VG}"/"${Test_volume}"
lvchange -ay -Ky "${VG}"/"${Test_volume}_snap_3"

sha256sum "/dev/${VG}/${Test_volume}_snap"*

lvs -a -o name,origin,lv_role| grep "${Test_volume}"

lvs output:

  test                                   public,origin,thinorigin,multithinorigin
  test_snap_0              test   public,snapshot,thinsnapshot            
  test_snap_1              test   public,snapshot,thinsnapshot            
  test_snap_2              test   public,snapshot,thinsnapshot            
  test_snap_3              test   public,snapshot,thinsnapshot 

now merge one snapshot:

lvconvert --merge "${VG}/${Test_volume}_snap_2"

lvs -a -o name,origin,lv_role| grep "${Test_volume}"

output:

  test                                 public                                  
  test_snap_0                     public                                  
  test_snap_1                     public                                  
  test_snap_3                     public

this snapshots are now just volumes, they may share some blocks with each other, sha256sum shows that data are intact, overriding one does not affect others.

It's quite strange why they lose origin but still have common data blocks.

journald does everything I need except listen on the UDP port. I want to use syslog-ng as a forwarder from the UDP port to journald. There's a simple program called 'udp514-journal' that can handle this. However, syslog-ng seems more reliable and functionally capable (with TLS encryption and filters). There are many examples of how to forward logs from journald to syslog-ng, but I'm trying to achieve the opposite. Is this possible?

I have

table ip nat {
    chain Redirect_to_local {
            limit rate 3/minute burst 10 packets log prefix "[nft.ip.dnat.8080]: "
            redirect to :8080
    }
    chain PREROUTING {
            type nat hook prerouting priority dstnat; policy accept;
            iifname != { "lo", "ISP*" } fib daddr type != { local, multicast, broadcast } udp dport == 8000 counter jump Redirect_to_local
    }
}

and it's incorrect because transport protocol mapping is only valid after transport protocol match. But why? It DID match, but not directly there.

If I add udp dport == 8000 before redirect it will be accepted as correct, despite duplication of rule (which is annoying).

Is there a way to overcome this? Or did I misunderstand this?

It is not clear to me from the manual if this commands are equal in their function:

meta skuid == "root" counter accept
skuid 0 counter accept

also

ct state == { established,  related } counter accept
ct state established,related counter accept

My questions about syntax is:

1. can I skip word meta (seems it must be skipped when item used in log flags)?
2. can I add == sign in any command that match something (for readability)?
3. can I write list (set of items) as item1,item2 and not { item1, item2 } or it's only for ct command?

I have set up strongswan for IPsec connection (remote Win10 to my Linux router). IPsec does not have interface by default but I don't want to risk exposing VPN traffic on my WAN interface. So I setup VTI interface with mark (https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN#Configuration) and I see traffic going through this virtual interface and not WAN. But there is still some traffic going through WAN interface. tcpdump on WAN (10.1.0.2 is Win10 client):

IP 10.1.0.2.137 > 255.255.255.255.137: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
IP 10.1.0.2.137 > 255.255.255.255.137: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
IP 10.1.0.2.137 > 255.255.255.255.137: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
IP 10.1.0.2.54995 > 239.255.255.250.3702: UDP, length 1072
IP 10.1.0.2.53313 > 239.255.255.250.1900: UDP, length 137
IP 10.1.0.2.54995 > 239.255.255.250.3702: UDP, length 1072

Private LAN sending packets to ISP interface is really bad. This packets nor marked nor have ipsec policy applied (iptables -A INPUT/OUTPUT/FORWARD -m policy --dir in/out --pol ipsec -j LOG-DROP-IPSEC does not see it). Filtering by source

iptables -t mangle -A POSTROUTING -s 10.1.0.2 -j LOG-DROP-IPSEC

cause no effect.

This packets seems actually go to WAN network: journalctl -k

...
... host *.*.*.*/if2 ignores redirects for 10.1.0.2 to 10.1.0.2
...

Where is this packets injected so that mangle POSTROUTING missing it and how to block them?

Most SNAT examples give following

iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source 100.200.100.200

but, it appears that this apply not only to forwarded packets but also to packets coming from localhost. This is unwanted. Outgoing packets from localhost may be something important (SMTP, etc), I don't want to change it's IP to one used for NAT.

I saw examples with

iptables -t nat -A POSTROUTING -s 10.0.0.0/8 -o eth0 -j SNAT --to-source 100.200.100.200

but this seems to be unreliable to me as it is one more place that you need to keep an eye on when you want change something. Is there a way to define that outgoing packets from localhost should not be SNAT'ed no matter what?

I have configured postfix to use virtual mailboxes, it reads "virtual_mailbox_domains" for my virtual domains (I have only one domain). But I have run into confusion - what should I do with variables

mydestination, mydomain, myhostname, myorigin

Didn't find any HowTo that clarify this. I saw different variations - some of this variables empty, some set to one of virtual domains, some are localhost, some is set to "domain.not.used.for.virtual.domains.com, localhost" Can I set all this variables to just "localhost" when using virtual mail domains?