FreeIPA: whoami via curl

Posted on by
Reply

Assuming PRINCIPAL is your Kerberos principal and $IPASERVER is the FQDN of your server, you can query your identity on the IPA server via curl:

kinit $PRINCIPAL
curl -k -H referer:https://$IPASERVER/ipa   -H "Content-Type:application/json"    -H "Accept:applicaton/json"   --negotiate -u :   --cacert /etc/ipa/ca.crt   -d  '{"method":"whoami","params":[[],{"version": "2.220"}],"id":0}'   -X POST    https://$IPASERVER/ipa/json
{"result": {"object": "user", "command": "user_show/1", "arguments": ["ayoung"]}, "version": "4.5.4", "error": null, "id": 0, "principal": "ayoung@YOUNGLOGIC.COM"}

This is handy if your system is not registered as an IPA client.

To fetch by username:

curl -k -H referer:https://$IPASERVER/ipa   -H "Content-Type:application/json"    -H "Accept:applicaton/json" --negotiate -u : --cacert /etc/ipa/ca.crt -d '{"method": "user_show", "params": [[ "ayoung" ], { "all": true, "rights": true }  ]}'  -X POST    https://$IPASERVER/ipa/json

Scoped versus unscoped RBAC

Posted on by
Reply

Role Based Access Control (RBAC) as defined by NIST is based on the concept of global roles. Global, in this case, means the scope of the application. So if you have the role of ADMIN, and you are in a globally scoped RBAC based application, that role applies to all APIs and resources within the program.

OpenStack was written assuming that the ADMIN role was a global role. But then it was implemented as a non-global role. It was implemented as a role scoped to a tenant. The term tenant was the original (and I would argue, better) term for what was later called Project, and then again expanded to Domains as well.

Continue reading →

Fetching all packages from a Koji build

Posted on by
1 
#bin/bash

KOJI_URL=https://kojipkgs.fedoraproject.org/packages/kernel/6.12.0/0.rc3.20241015giteca631b8fe80.32.eln143/aarch64/ 

curl $KOJI_URL > aarch64.dir.html
for  PACKAGE in  `xmllint --html  --xpath "//html/body/pre/a/@href" aarch64.dir.html | awk -F\" 'NR % 2 == 0 { print $2 }' `;  
do 
        URL=$KOJI_URL/$PACKAGE ;
        echo $URL; wget $URL;
done

Modify the URL to fetch a different architecture, version, or package.

The version of xmllint I am running does not support fn:string. If it did, the “for PACKAGE” line can be redone as:

for  PACKAGE in  `xmllint --html  --xpath "string(//html/body/pre/a/@href)" aarch64.dir.html` ;

The development cycle

Posted on by
Reply

how to clean up code.

  • run your code to make sure it works
  • while (work_to_do){
  • make a small change
  • test it
  • commit to git
  • }
  • push to git server on local branch
  • try it on another machine
  • collapse git commits for code review
  • test
  • post for code review

How to add a new feature

  • run your code make sure it works
  • while (work_to_do){
  • write a small test
  • while (test doesn’t pass){
    • make a small change
    • test it
    • }
  • commit to git
  • }
  • push to git server on local branch
  • try it on another machine
  • collapse git commits for code review
  • test
  • post for code review

Parsing a yum repo with XPath

Posted on by
Reply

https://gnome.pages.gitlab.gnome.org/libxml2/xmllint.htmlLets say you want to see what src RPMs are in a given yum repo. If the author used createrepo to create the yum repo, it should be an a fairly standard layout. The following xpath query should pull it out.

Note that you can get xmllint to run the xpath query from libxml2


curl http://$yumserver/$somerepo/ > repo.html
xmllint --html  --xpath "//html/body/table/tr/td/a/@href" repo.html | grep src

The portion of the query a/@href will match a tag like this

<a href="https://blam.src.rpm">

More Personal Ansible

Posted on by
Reply

I can do anything. I can’t do everything. –Me

Anything worth doing is worth doing in a way you can check in to git. To recall what I did from the command line, I should turn those actions into a persist-able document. Do I? Not often enough. Often I rely on bash history to remind me of what I did last time. Since the machines I work on are out of a global pool, I have been burned by not recording commands before relinquishing a machine.

For complex series of tasks, it makes sense to execute a bash script to perform those tasks, and I have many of these. Shell scripting excels in doing command line tasks. Where it does not do so well is on tasks that are split over multiple machines. While curl is great for pulling and pushing files to webservers, the majority of my remote work requires ssh and scp to set things up. This is where Ansible comes in: If I can make a playbook that records the commands I use to perform that action, I can repeat it on another machine.

Here is what my workflow looks like as I try to get better at it:

Continue reading →