First you need to give your admin account access, usually only the acutual root-user on the system hast this permission.
Prepare the follwing foo.ldif:
dn: olcDatabase={0}config,cn=config
changetype: modify
replace: olcAccess
olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by dn.exact=cn=admin,dc=example,dc=com manage by * break
and execute:
sudo ldapmodify ldapmodify -Y EXTERNAL -H ldapi:/// -f foo.ldif
after that, you need to edit the phpldapadmin config.php:
$servers->setValue('server','base',array('cn=config','dc=example,dc=org'));
2018-04-12
growing partitions in linux
Situation:
Solution:
- Linux Virtual Machine
- Disk is to small
- Growing the virtual disk online is possible
- How do you get to use the additional space in linux?
Solution:
- Find out which scsi address to use ls /sys/class/scsi_disk
- force a rescan of the device echo 1 > /sys/class/scsi/1\:0\:0\:0/device/rescan
- grow the partition growpart /dev/sdb 1
- grow the filesystem i.e. xfs_growfs /mnt/data
2016-12-17
Install packages from debian backports with puppet
Let's say we have a list of packages you want to install from backports like this:
$backports = [ 'pkg1', 'pkg2' ]There are a couple of things you have to do:
Add the backports repository to sources.list(.d)
apt::source { 'debian-backports':
location => "ftp://$SERVER/debian",
repos => 'main contrib non-free',
release => 'jessie-backports'
}
pin the packages to a priority of 500 or higher
apt::pin { 'backports_packages':
packages => $backports,
priority => 600,
release => 'jessie-backports'
}
set "ensure => latest", not installed/present
package { $backports: ensure => latest }
Debian Mirror / Another fix for hashsum mismatch
At work I am running a debian mirror for a bunch of client machines. I needed packages from the backports, so I added the backports to mirror and got this nice error:
For a complete mirror you can use this script:
W: Failed to fetch ftp://$SERVER_AT_WORK/debian-backports/dists/jessie-backports/main/binary-amd64/Packages Hash Sum mismatchTurns out, the old mirror structure from debian wheezy cannot be used for a jessie-mirror, you need to use the same directory structure as on the offical mirrors (ftp://$SERVER_AT_WORK/debian/dists/jessie-backports).
For a complete mirror you can use this script:
2016-06-23
use Ericsson H5321 gw mobile broadband as GPS, Gentoo Linux Edition
These are mostly notes for my self, but may be useful for others.
other pages say this only works with a sim inserted, it doesn't need to have an active registration though
# lsusb
0bdb:1926 Ericsson Business Mobile Networks BV
kernel modules are needed, since I did not find any documentation, these are in use on my system:
CONFIG_USB_NET_CDC_MBIM
CONFIG_USB_NET_CDC_NCM
CONFIG_USB_WDM
CONFIG_USB_ACM
Not sure if this is needed, but it works with it being there
# cat /etc/modprobe.d/cdc_ncm.conf
options cdc_ncm prefer_mbim=N
options cdc_ncm prefer_mbim=N
ModemManager needs to be running, so
# systemctl enable ModemManager; systemctl start ModemManager
disable the pin on the sim
# mmcli -i 0 --pin=1234 --disable-pin
then we can activate gps via mmcli for testing:
# mmcli -m 0 --location-enable-gps-nmea
# mmcli -m 0 --location-enable-gps-raw
# mmcli -m 0 --location-get
this should ouptut stuff, once you have a fix you should get a longitude and latitude in the raw section
if you want gui stuff to work:
disable nmea and raw gps, activate unmanaged:
# mmcli -m 0 --location-enable-gps-unmanaged
this allows gpsd to open /dev/ttyACM2, while the modemmanager activates stuff on the control device (ttyACM1)
for testing without forking "-N"
# gpsd -N /dev/ttyACM2
then you need to start a client like foxtrotgps
after that, not before! you have to
# echo -e "AT*E2GPSNPD\r" >/dev/ttyACM2
to persuade the modem to really start giving you values
once you close the client (foxtrotgps) however, gpsd closes the device, which means you have to do the echo stuff again after you connect a client
2014-09-06
Response to Modern anti-spam and E2E crypto
This is a response to this email: https://moderncrypto.org/mail-archive/messaging/2014/000780.html?hn (I don't want to sign up to a mailing list just to send one reply, especially when I want it to be public).
If you haven't read the mail I suggest you at least skim it.
tl;dr: Spam fighting relies heavily on the provider being able to read emails plain text itself. The question is how to solve that problem in the case of "almost everyone uses end to end encryption".
It seems to me only the negative sides of end to end cryptography are seen. There is a lot it can do for us, maybe even eliminate spam altogether. Basically there are types of email we have to consider:
I have a friend (or any kind of person I somehow know directly) and want to exchange emails with him or her. Easy: I get my friends public key and tell my provider "I trust this public key, please let the mails through". He or she does the same. Done.
I have I company I want to receive mail from. It doesn't matter if I sign up with some social site or just want a receipt, I get the public key off their web site and do the same thing as above. If the company wants to receive answers from me I tell them my public key after account creation, which has to be shielded against spam account creation anyways.
The only difficult case is when I want to receive emails from addresses I don't know before. There are several sub cases here, which have different difficulties of solving the problem.
1. Company to company mails. Easy: Sign all mails with the company mail server and trust that key on the other company mail server.
2. Company to client mail. wait, since when do we want to receive mail from a company we don't know? Generally speaking, I wouldn't want to. In the small number of cases where I might want to, it would probably be ok to contact me another way first. Example: The local electricity company wants to send me the bill via email. If I don't know them since I moved to my appartment / house / whatever, they can send me a letter first and all is well. State emails are another thing, but there could be a general "This is a state mail" public key. I honestly can't think of any case where I would want to receive an email from a non-person-address I don't know and where a letter before wouldn't be the way to go.
3. Client to company mail. This is where it gets a little complicated. However there would still be the solution of "create account (CAPTCHA protected and whatnot), submit your key, done.
4. Person to Person. Someone reads a blog post and wants to reply to that on a personal level. Okay, this is the only case where I don't have a perfect solution in my mind. However until this case there are a lot of mails that got sent. Now we can talk about reputation on the provider end (how many accounts did not reject how many mails from this account), about web of trust (Would it not be awesome to let that "everyone knows everyone via 7 persons" mantra of social networking do the work for you?) and about friend requests. Yes, friend requests for emails, why the hell not? Key signing is just a technical way of expressing that (note: the word friend in "friend request" should not be read to literally). One can set rules as soft or as hard as one wants: Only one friend request per domain before one accepts any more mail? Or just "only a friend request per address before more mail to this account".
Yes I make it sound easy when it is a lot of work. But I say it's less work than plain text spam fighting.
Yes the client side tools are shitty. We need a lot of work to make that stuff usable. However it is entirely possible: Smartphones and qr codes make public key exchange easy. Add the email to the address book in the same function and it just got easier than before. We need good common APIs from email providers to send them keys we trust or do not trust anymore.
Yes, signing every mail outside of the encryption makes us horribly trackable. I don't have a perfect solution here, however not doing it isn't one either. As long as everything is sent from the same account it doesn't matter anyway. And there is always the possibility of the web of trust of self, where a different key is used for every email account, every contact, however you like it and where you can let all the keys trust each other secretly. Good keychain software is needed of course, but it is any case, if we ever want to bring end to end encryption to the masses and maybe solve the "I have to many passwords" problem on the way.
Please tell me if I have obvious flaws in my arguments, if I just overlooked some cases or if you have better ideas.
If you haven't read the mail I suggest you at least skim it.
tl;dr: Spam fighting relies heavily on the provider being able to read emails plain text itself. The question is how to solve that problem in the case of "almost everyone uses end to end encryption".
It seems to me only the negative sides of end to end cryptography are seen. There is a lot it can do for us, maybe even eliminate spam altogether. Basically there are types of email we have to consider:
I have a friend (or any kind of person I somehow know directly) and want to exchange emails with him or her. Easy: I get my friends public key and tell my provider "I trust this public key, please let the mails through". He or she does the same. Done.
I have I company I want to receive mail from. It doesn't matter if I sign up with some social site or just want a receipt, I get the public key off their web site and do the same thing as above. If the company wants to receive answers from me I tell them my public key after account creation, which has to be shielded against spam account creation anyways.
The only difficult case is when I want to receive emails from addresses I don't know before. There are several sub cases here, which have different difficulties of solving the problem.
1. Company to company mails. Easy: Sign all mails with the company mail server and trust that key on the other company mail server.
2. Company to client mail. wait, since when do we want to receive mail from a company we don't know? Generally speaking, I wouldn't want to. In the small number of cases where I might want to, it would probably be ok to contact me another way first. Example: The local electricity company wants to send me the bill via email. If I don't know them since I moved to my appartment / house / whatever, they can send me a letter first and all is well. State emails are another thing, but there could be a general "This is a state mail" public key. I honestly can't think of any case where I would want to receive an email from a non-person-address I don't know and where a letter before wouldn't be the way to go.
3. Client to company mail. This is where it gets a little complicated. However there would still be the solution of "create account (CAPTCHA protected and whatnot), submit your key, done.
4. Person to Person. Someone reads a blog post and wants to reply to that on a personal level. Okay, this is the only case where I don't have a perfect solution in my mind. However until this case there are a lot of mails that got sent. Now we can talk about reputation on the provider end (how many accounts did not reject how many mails from this account), about web of trust (Would it not be awesome to let that "everyone knows everyone via 7 persons" mantra of social networking do the work for you?) and about friend requests. Yes, friend requests for emails, why the hell not? Key signing is just a technical way of expressing that (note: the word friend in "friend request" should not be read to literally). One can set rules as soft or as hard as one wants: Only one friend request per domain before one accepts any more mail? Or just "only a friend request per address before more mail to this account".
Yes I make it sound easy when it is a lot of work. But I say it's less work than plain text spam fighting.
Yes the client side tools are shitty. We need a lot of work to make that stuff usable. However it is entirely possible: Smartphones and qr codes make public key exchange easy. Add the email to the address book in the same function and it just got easier than before. We need good common APIs from email providers to send them keys we trust or do not trust anymore.
Yes, signing every mail outside of the encryption makes us horribly trackable. I don't have a perfect solution here, however not doing it isn't one either. As long as everything is sent from the same account it doesn't matter anyway. And there is always the possibility of the web of trust of self, where a different key is used for every email account, every contact, however you like it and where you can let all the keys trust each other secretly. Good keychain software is needed of course, but it is any case, if we ever want to bring end to end encryption to the masses and maybe solve the "I have to many passwords" problem on the way.
Please tell me if I have obvious flaws in my arguments, if I just overlooked some cases or if you have better ideas.
2014-08-24
I love btrfs
As I said before btrfs has raid support. That is just the newest thing I learned about it. What is also great is its support for subvolumes and snapshots. Since snapshots are copy-on-write they are instant and only cost storage capacity once you start changing files. snapshots are read only by default, which is good for backups, but can of course be duplicated to standard subvolumes, which ca be mounted at boot as root file system. So with a small amount of bash scripting and a cron job you can get a local timemachine like backup system. The script could also take care of adding entries to your boot manager. And you don't even have to revert to a state where your system worked an throw all changes out the window, you can keep those in a snapshot.
But since local snapshots are a little useless when the disk fails one needs external backup. btrfs can transfer diffs between snapshots :)
Yep, thats it, but aren't the simple "hey something works" reads the best?
But since local snapshots are a little useless when the disk fails one needs external backup. btrfs can transfer diffs between snapshots :)
Yep, thats it, but aren't the simple "hey something works" reads the best?
Subscribe to:
Posts (Atom)