• it is recommended to store puppet manifests (*.pp) and related files in a VCS (i.e. git)
• it is not recommended to store password in a VCS

• serve password in a separate file/DB or do an extlookup on the master (pre-set passwords)
• store password on the server and get them through a generate function (random password but on the master)

• the password is generated and stored on the node
• no VCS commit of your password
• no DB storage of your password beside the local filesystem of the host
• no need to use a common pre-set password for all you host, the password is randomly generated for only one host
• to steal the password you need to crack the host first but if you have root access on the host, accessing a random generated password is pointless

• the password is stored in clear text
• the password is only protected by the filesystem ACL

node "mysqlserver"  
  package  
    ["mysql-server",
     "mysql-client",
     "sekred"]:
      ensure => installed;
   
  service  
    "mysqld":
      name => "mysql",
      ensure => running,
      hasrestart => true,
      hasstatus => true;
   
  exec  
    "mysql-set-root-password":
      command => "mysqladmin -u root password $(sekred get root@mysql)",
      onlyif => "mysql -u root",  # Trigger only if password-less root account.
      require => [Service["mysqld"], Package["mysql-client", "sekred"]];
   
 

$> sekred get root@mysql
Cie8ieza

define user::template ()  
  user  
    $name:
      ensure => present,
      membership => minimum,
      shell => "/bin/bash",
      ....
   
  include "ssh_keys::$name"
  # Check password less account and set one, if required.
  $user_passwd="$(sekred get --uid $name $name@login)"
  exec  
    "user-set-default-password-$name":
      command => "echo $name:$user_passwd   chpasswd",
      onlyif => "test \"$(getent shadow $name   cut -f2 -d:)\" = \"!\"",
      require => [User[$name], Package["sekred"]];
   
 

1. Lecture on a brief history of open source and the free software movement
2. Small research project on an open source project
3. Lab where students could work through OpenHatch's training missions

(import requests)
 
(setv req (requests.get "http://hy.pault.ag"))
(if (= req.status_code 200)
  (for (kv (.iteritems req.headers))
    (print kv))
  (throw (Exception "Wrong status code")))

('date', 'Wed, 03 Apr 2013 12:09:23 GMT')
('connection', 'keep-alive')
('content-encoding', 'gzip')
('transfer-encoding', 'chunked')
('content-type', 'text/html; charset=utf-8')
('server', 'nginx/1.2.6')

If it is the first download, the maintainer creates a new git repository. If it has been packaged before, he clones the repository. The important point here is that this is not the upstream repository, it is an independent repository for Debian packaging.

• For historical reasons that are continuingly vanishing in importance, Debian fetishises the tarballs produced by upstream. While upstreams increasingly consider them an unimportant distraction, Debian insists in hoarding and rolling around in on its nest of gleaming pristine tarballs. I wrote pristine-tar to facilitate this behavior, while also pointing fun at it, and perhaps introducing a weak spot with which to eventually slay this particular dragon. It is widely used within Debian. .. Anyway, the point is that it's no problem to import upstream's tarball into a clone if their git repository. It's fine if that tarball includes files not present in their git repository. Indeed, upstream can do this at release time if they like. Or Debian developers can do it and push a small quantity of data back to upstream in a branch.
• Sometimes tagged releases in upstream git repositories differ from the files in their released tarballs. This is actually, in my experience, less due to autotools generated files, and more due to manual and imperfect release processes, human error, etc. (Arguably, autotools are a form of human error.) When this happens, and the Debian developer is tracking upstream git, they can quite easily modify their branch to reflect the contents of the tarball as closely as they desire. Or modify the source package uploaded to Debian to include anything left out of the tarball. My favorite example of this is an upstream who forgot to include their README in their released tarball. Not a made up example; as mentioned tarballs are increasingly an irrelevant side-show to upstreams. If I had been treating the tarball as canonical I would have released a package with no documentation.
• Whenever Debian developers interact with upstream, whether it's by filing bug reports or sending patches, they're going to be referring to refs in the upstream git repository. They need to have that repository available. The closer and better the relationship with upstream, the more the DD will use that repository. Anything that pulls them away from using that repository is going to add friction to dealing with upstream. There have, historically, been quite a lot of sources of friction. From upstreams who choose one VCS while the DD preferred using another, to DDs low on disk space who decided to only version control the debian directory, and not the upstream source code. With disk space increasingly absurdly cheap, and the preponderance of development converging on git, there's no reason for this friction to be allowed to continue.

Filed under: English Phpmyadmin Suse Weblate 0 comments Flattr this!

brew tap petere/postgresql
brew install postgresql-9.2
# etc.
brew install --HEAD postgresql-common

pg_createcluster 9.2 main
pg_ctlcluster 9.2 main start
pg_lsclusters

• homebrew-postgresql
• postgresql-common homebrew branch

• Throughout the GNOME documentation and tools, "schema", "key" and "path" are used nearly interchangeably to mean roughly the same thing. (I think a path describes a key within a schema, to be precise.)
• schemas/keys/paths "must start with and end with a forward slash character", except when they mustn't, such as in override files, where you must use a dot, and you don't prefix or suffix the schema/key/path with dots. In fact the command line gsettings tool only accepts dotted schemas, not slash-separated ones.
• Sometimes, people choose XML, and save themselves the trouble of writing a custom parser, but at the expense of ease for humans having to read or write files. gsettings uses XML for schema files, but a separate ini-style format for override files. Everybody wins?
• glib-compile-schemas requires a path argument, so all your schema and override files must be in the same place. Sites have to lump stuff into /usr/share/glib-2.0/schemas alongside distribution files, rather than separated out to (say) /usr/local/share/glib-2.0/schemas.
• It's quite possible to get an override file past glib-compile-schemas which non-the-less is broken. The result is gsettings clients, including the gsettings binary itself, complaining and then segfaulting. Do not rely on glib-compile-schemas to ensure compliant override files.
• glib-compile-schemas would appear to read override files in native byte order, so make sure you name your override so that it sorts after any distribution-provided overrides. E.g., 20_my_gnome-shell.gschema.override to sort after 10_gnome-shell.gschema.override.

1. I can't tell the thing that I never ever ever want to write HTML-formatted emails. While there is an option "Compose messages in HTML format" in the "Account settings" dialog, that only seems to impact the behaviour of the client upon "new mail", not its reply behaviour, forcing me to go to Options->Format and switch it off.
2. To make matters worse, the HTML editor and the plain-text editor are not the same dialog. That means it is not possible to switch on HTML formatting if it wasn't on originally (not a problem for me, but I can imagine it being a problem for others), but also that the fugly quoting style (vertical line next to the text) of the HTML editor is not removed when you switch from HTML to plain-text. Further on, it has issues when you want to remove white space, where it will remove entire quoting levels rather than just an empty line. This is horrible, horrible behaviour.
3. While there is support for multiple email addresses connected to the same IMAP account, it does appear that there is no support for automatically choosing the right email address based on user-defined rules, such as "which mail folder are we currently in". Having to remember that I need to select the right mail address is tiresome and error-prone; e.g., when I'm in a Debian-related mail folder, I want my mail client to use my Debian mail address automatically. It appears the only way in which icedove can automatically select sender addresses is by checking the recipient list in the To: and Cc: headers for any of its configured mail addresses, and using that to decide what to put in the from: header.

• Gateway for the external network connection
  • Routing to internal ethernet
  • 2.4GHz wifi router
  • 5GHz wifi router
• Printer server
• House NAS
  • Backup server (syncing externally as well)
  • DLNA server
• mpd server
• ATSC based PVR

• there is brand recognition there from when I lived in Canberra and used ActewAGL
• it looks like I can sign up online without having to talk to anyone (as soon as my damn mobile phone number ports over to Internode and starts working)
• they're first on the list of electricity retailers