Re: SL 6.7 Kernel headers misses typedef sa_family_t

[André Hartmann]

Dear Mark,

thanks for your investigation.

Indeed, I had included linux/can.h before sys/socket.h (which includes 
bits/sockaddr.h, and should *not* be included directly) so the compiler 
struggled.


After swapping the include lines, and including sys/socket.h before 
linux/can.h, it compiles fine.


So again, many thanks!

Best regards,
André


Am 14.01.2016 um 15:33 schrieb Mark Stodola:

On 01/14/2016 04:06 AM, André Hartmann wrote:

Hello List,

I have written a program which uses SocketCAN for CAN communication.
The development takes place under Ubuntu Linux and compilation is fine
there (also cross-compilation for an embedded ARM Linux).

But when I compile my program under Scientific Linux 6.7, I get the
following errors:

"
In file included from socket_can/receivethread.h:6,
  from socket_can/receivethread.c:4:
/usr/include/linux/can.h:81: error: expected specifier-qualifier-list
before 'sa_family_t'
socket_can/receivethread.c: In function 'receivethread_init':
socket_can/receivethread.c:52: error: 'struct sockaddr_can' has no
member named 'can_family'
socket_can/receivethread.c:53: error: 'struct sockaddr_can' has no
member named 'can_ifindex'
"

Searching for the definition of sa_family_t gave a lot of usages,
but no definition:

$ cd /usr/include/linux
$ grep -r sa_family_t
llc.h:sa_family_t sllc_family;/* AF_LLC */
llc.h:sa_family_tsllc_arphrd;/* ARPHRD_ETHER */
llc.h:unsigned char   __pad[__LLC_SOCK_SIZE__ - sizeof(sa_family_t)
* 2 -
rose.h:sa_family_tsrose_family;
rose.h:sa_family_tsrose_family;
x25.h:sa_family_t   sx25_family;/* Must be AF_X25 */
if_pppox.h:   sa_family_t sa_family;/* address
family, AF_PPPOX */
if_pppox.h:sa_family_t sa_family;  /* address family,
AF_PPPOX */
in.h:  sa_family_tsin_family;/* Address family*/
ax25.h:sa_family_tsax25_family;
ipx.h:sa_family_tsipx_family;
netlink.h:#include  /* for sa_family_t */
netlink.h:sa_family_tnl_family;/* AF_NETLINK*/
can.h:sa_family_t can_family;
phonet.h:sa_family_t spn_family;
phonet.h:__u8 spn_zero[sizeof(struct sockaddr) - sizeof(sa_family_t)
- 3];
un.h:sa_family_t sun_family;/* AF_UNIX */
irda.h:sa_family_t sir_family;   /* AF_IRDA */
atalk.h:sa_family_t  sat_family;

If I add the typedef to socket.h, everything is fine until the next
kernel update:

typedef unsigned short sa_family_t;

The system is:

$ uname -a
Linux sl67-x64 2.6.32-573.12.1.el6.x86_64 #1 SMP Tue Dec 15 08:24:23 CST
2015 x86_64 x86_64 x86_64 GNU/Linux

Any opinion on this?

Best regards,
André


It looks like sa_family_t has been morphing over time.  In SL5, it is
indeed defined in linux/socket.h.  In SL6 I find it defined in
bits/sockaddr.h.  In SL7 it continues to be in bits/sockaddr.h, but
there is also __kernel_sa_family_t defined in linux/socket.h.

Try adding bits/sockaddr.h to your includes.

-Mark

Re: Kickstart / PXE / Cobbler / Ansible

[Denice]

On Thu, 14 Jan 2016, Benjamin Lefoul wrote:


...
Someone just mentioned Cobbler, and the fact that it's RH's baby. Is
 this in any way linked to the recent acquisition of Ansible ?
In fact, I never really understood what Ansible was, and does it have
 its place in automated install? Can it replace Kickstart?

As you can see I am pretty naive about the topic...


We have been getting started on Ansible.

Note that Red Hat has purchased Ansible - it has all the hallmarks of
a product that suits Red Hat very well - python-based, a model built
around a readily available, open-source product, with a purchase model
(Ansible Tower) of the GUI-side of the product for an enterprise crowd.

I quite like what I see so far.  It does not replace Kickstart, but
you can use Ansible during kickstart in an 'ansible-pull' mode.
By default, the daily administration mode is typically push mode -
that is - using ssh from a management node you push out your changes.

The idea is to set up 'roles' that manage typical tasks - for example,
configuring local ntp, or managing ssh host keys.  During kickstart you would
just run, or as they say 'play', those roles.

Fedora's infrasture uses Ansible:
  https://infrastructure.fedoraproject.org/cgit/ansible.git

cheers, etc.
--
deatrich @ triumf.ca, Science/ATLAS PH: +1 604-222-7665
<*> This moment's fortune cookie:
Live in a world of your own, but always welcome visitors.

SL 6.7 Kernel headers misses typedef sa_family_t

[André Hartmann]

Hello List,

I have written a program which uses SocketCAN for CAN communication.
The development takes place under Ubuntu Linux and compilation is fine 
there (also cross-compilation for an embedded ARM Linux).


But when I compile my program under Scientific Linux 6.7, I get the 
following errors:


"
In file included from socket_can/receivethread.h:6,
 from socket_can/receivethread.c:4:
/usr/include/linux/can.h:81: error: expected specifier-qualifier-list 
before 'sa_family_t'

socket_can/receivethread.c: In function 'receivethread_init':
socket_can/receivethread.c:52: error: 'struct sockaddr_can' has no 
member named 'can_family'
socket_can/receivethread.c:53: error: 'struct sockaddr_can' has no 
member named 'can_ifindex'

"

Searching for the definition of sa_family_t gave a lot of usages,
but no definition:

$ cd /usr/include/linux
$ grep -r sa_family_t
llc.h:  sa_family_t sllc_family;/* AF_LLC */
llc.h:  sa_family_t sllc_arphrd;/* ARPHRD_ETHER */
llc.h:  unsigned char   __pad[__LLC_SOCK_SIZE__ - sizeof(sa_family_t) * 2 -
rose.h: sa_family_t srose_family;
rose.h: sa_family_t srose_family;
x25.h:  sa_family_tsx25_family; /* Must be AF_X25 */
if_pppox.h:   sa_family_t sa_family;/* address 
family, AF_PPPOX */

if_pppox.h: sa_family_t sa_family;  /* address family, AF_PPPOX */
in.h:  sa_family_t  sin_family; /* Address family   
*/
ax25.h: sa_family_t sax25_family;
ipx.h:  sa_family_t sipx_family;
netlink.h:#include  /* for sa_family_t */
netlink.h:  sa_family_t nl_family;  /* AF_NETLINK   */
can.h:  sa_family_t can_family;
phonet.h:   sa_family_t spn_family;
phonet.h:   __u8 spn_zero[sizeof(struct sockaddr) - sizeof(sa_family_t) - 
3];
un.h:   sa_family_t sun_family; /* AF_UNIX */
irda.h: sa_family_t sir_family;   /* AF_IRDA */
atalk.h:sa_family_t   sat_family;

If I add the typedef to socket.h, everything is fine until the next 
kernel update:


typedef unsigned short sa_family_t;

The system is:

$ uname -a
Linux sl67-x64 2.6.32-573.12.1.el6.x86_64 #1 SMP Tue Dec 15 08:24:23 CST 
2015 x86_64 x86_64 x86_64 GNU/Linux


Any opinion on this?

Best regards,
André

Re: a year later - CERN move to Centos - what are we doing?

[lejeczek]

On 13/01/16 19:30, Konstantin Olchanski wrote:

On Wed, Jan 13, 2016 at 07:59:43AM -0600, Alec T. Habig wrote:

Konstantin Olchanski writes:

The installer for both have the same idiotic "you *must* create a fake
user or no login prompt for you!",

If you're not making a local user, then you've probably got a network
authentication scheme.


Indeed. We use NIS. Support for NIS was removed in the el7 installer. Rejoyce!


In which case, you're probably deploying more than one machine.  Take a
look at making a kickstart file to automate the install process.  In
kickstart, you don't have to make a dummy user, you can just define your
network authentication setup.  And much, much more: then use that same
script to install on as many machines as you want.


Indeed. Have been using kickstart installs for years. CD/DVD kickstarts,
PXE-network-booted kickstarts, now mostly USB-flash-booted kickstarts.
Have you looked at / tired cobbler? It's great for larger 
deployment but also good for smaller, even only a few 
machines environment.
It's not too heavy, not to over complicated and quite 
flexible, it's all what you do already, only it glues it all 
together + a web interface.
And with good support as it's Redhat's own thing, or was, I 
think.




In our environement we cannot do a one-size-fits-all kickstart,
so possibility to configure NIS during installation was quite handy.
Now it becomes a post-install step - login as root, run authconfig.

Actually now, due to this "must create, then delete fake user, which will also 
use a UID
colliding with our historic UID allocation scheme", non-kickstart vanilla
installer is pretty much useless.


and the same "you *must* use the disk partition tool designed by
dummies for dummies".

likewise solved by kickstart.


The kickstart disk partitioning tool is even dumber than they new GUI tool,
only useful for "one-size-fits-all" cases where you also do not mind 
accidentally
deleting the contents of all disks. (yes, open the machine, disconnect disks,
install, reconnect disks, close the machine, thanks, but no thanks).

At least the el7 installer does not overwrite the bootloader of the *installer* 
disk
and seems to correctly install the boot loader for raid1 mirrored slash 
partitions.

P.S.

I keep banging about all this stuff because over the last 20 years all I see
is each new installer only reluctantly fix a few of the old bugs, but 
consistently
add new "features" which are not improvements.

Re: a year later - CERN move to Centos - what are we doing?

[Jarek Polok]

On 01/14/2016 07:42 AM, Yasha Karant wrote:

For the immediate future, we plan to continue with SL 7.  When EL 8
emerges, we may need to re-evaluate the situation.  That being stated,
for non-CERN groups (that is, groups neither employed by CERN nor in one
of the collider collaborations), is there a CERN equivalent to this SL
list?


No, not really: we provide support for CERN staff/users and collaborators.


What "services" does linux.supp...@cern.ch provide?  I understand that
for CERN groups, the service presumably is close to what RH provides to
contract for-fee customers, with the proviso that the CS persons with
CERN groups know what they are doing.


Yes, that is more or less it.


What is available to non-CERN
groups/persons?


'Best effort' policy: we will try to solve the problem,
resources permitting.

Best Regards

Jarek

__
---
_ Jaroslaw_Polok ___ CERN - IT/CM/LCS _
_ http://cern.ch/~jpolok  tel_+41_22_767_1834 _
__+41_75_411_9487 _

Kickstart / PXE / Cobbler / Ansible

[Benjamin Lefoul]

Hi all,

I am actually interested in the automated install topic (currently taking place 
in the other discussion, but I don't want to feed the troll so I'll start a new 
one).

Someone just mentioned Cobbler, and the fact that it's RH's baby. Is this in 
any way linked to the recent acquisition of Ansible ?
In fact, I never really understood what Ansible was, and does it have its place 
in automated install? Can it replace Kickstart?

As you can see I am pretty naive about the topic...

Thanks,

Benjamin

Re: Kickstart / PXE / Cobbler / Ansible

[lejeczek]

On 14/01/16 13:33, Benjamin Lefoul wrote:

Hi all,

I am actually interested in the automated install topic (currently taking place 
in the other discussion, but I don't want to feed the troll so I'll start a new 
one).

Someone just mentioned Cobbler,
that was the troll himself who has been using cobbler for 
years now.

and the fact that it's RH's baby. Is this in any way linked to the recent 
acquisition of Ansible ?
In fact, I never really understood what Ansible was, and does it have its place 
in automated install? Can it replace Kickstart?

As you can see I am pretty naive about the topic...

Thanks,

Benjamin

Re: Kickstart / PXE / Cobbler / Ansible

[Loris Bennett]

Hi Benjamin,

Benjamin Lefoul  writes:

> Hi all,
>
> I am actually interested in the automated install topic (currently
> taking place in the other discussion, but I don't want to feed the
> troll so I'll start a new one).
>
> Someone just mentioned Cobbler, and the fact that it's RH's baby. Is
> this in any way linked to the recent acquisition of Ansible ?  In
> fact, I never really understood what Ansible was, and does it have its
> place in automated install? Can it replace Kickstart?
>
> As you can see I am pretty naive about the topic...

I don't know very much about kickstart but am currently using ansible to
set up two administration servers for a test cluster.  My meagre
understanding is that kickstart is mainly aimed at the initial
lower-level installation (partitioning the disk, installing the base OS
and other packages, ...).

Ansible on the other hand requires the machines you are managing to be
already up and running and, normally, accessible via ssh.  Thus it seems
it is a more fancy way of doing what kickstart can probably do in the
post-install section.  However, Ansible works with 'playbooks', which are
sets of 'plays', which in turn are sets of tasks to be carried out on a
set of hosts.  You can run entire playbooks or just groups of tasks and
you can also define roles, such as 'ldapserver' or 'dbserver' to bundle
associated tasks together.  In general it seems slightly more orientated
towards automated day-to-day management of multiple, heterogeneous hosts.

That having been said, I am no expert.

Regards

Loris

-- 
Dr. Loris Bennett (Mr.)
ZEDAT, Freie Universität Berlin Email loris.benn...@fu-berlin.de

Re: SL 6.7 Kernel headers misses typedef sa_family_t

[Mark Stodola]

On 01/14/2016 04:06 AM, André Hartmann wrote:

Hello List,

I have written a program which uses SocketCAN for CAN communication.
The development takes place under Ubuntu Linux and compilation is fine
there (also cross-compilation for an embedded ARM Linux).

But when I compile my program under Scientific Linux 6.7, I get the
following errors:

"
In file included from socket_can/receivethread.h:6,
  from socket_can/receivethread.c:4:
/usr/include/linux/can.h:81: error: expected specifier-qualifier-list
before 'sa_family_t'
socket_can/receivethread.c: In function 'receivethread_init':
socket_can/receivethread.c:52: error: 'struct sockaddr_can' has no
member named 'can_family'
socket_can/receivethread.c:53: error: 'struct sockaddr_can' has no
member named 'can_ifindex'
"

Searching for the definition of sa_family_t gave a lot of usages,
but no definition:

$ cd /usr/include/linux
$ grep -r sa_family_t
llc.h:sa_family_t sllc_family;/* AF_LLC */
llc.h:sa_family_tsllc_arphrd;/* ARPHRD_ETHER */
llc.h:unsigned char   __pad[__LLC_SOCK_SIZE__ - sizeof(sa_family_t)
* 2 -
rose.h:sa_family_tsrose_family;
rose.h:sa_family_tsrose_family;
x25.h:sa_family_t   sx25_family;/* Must be AF_X25 */
if_pppox.h:   sa_family_t sa_family;/* address
family, AF_PPPOX */
if_pppox.h:sa_family_t sa_family;  /* address family,
AF_PPPOX */
in.h:  sa_family_tsin_family;/* Address family*/
ax25.h:sa_family_tsax25_family;
ipx.h:sa_family_tsipx_family;
netlink.h:#include  /* for sa_family_t */
netlink.h:sa_family_tnl_family;/* AF_NETLINK*/
can.h:sa_family_t can_family;
phonet.h:sa_family_t spn_family;
phonet.h:__u8 spn_zero[sizeof(struct sockaddr) - sizeof(sa_family_t)
- 3];
un.h:sa_family_t sun_family;/* AF_UNIX */
irda.h:sa_family_t sir_family;   /* AF_IRDA */
atalk.h:sa_family_t  sat_family;

If I add the typedef to socket.h, everything is fine until the next
kernel update:

typedef unsigned short sa_family_t;

The system is:

$ uname -a
Linux sl67-x64 2.6.32-573.12.1.el6.x86_64 #1 SMP Tue Dec 15 08:24:23 CST
2015 x86_64 x86_64 x86_64 GNU/Linux

Any opinion on this?

Best regards,
André


It looks like sa_family_t has been morphing over time.  In SL5, it is 
indeed defined in linux/socket.h.  In SL6 I find it defined in 
bits/sockaddr.h.  In SL7 it continues to be in bits/sockaddr.h, but 
there is also __kernel_sa_family_t defined in linux/socket.h.


Try adding bits/sockaddr.h to your includes.

-Mark

Re: Kickstart / PXE / Cobbler / Ansible

[Stephen John Smoogen]

On 14 January 2016 at 06:33, Benjamin Lefoul  wrote:
> Hi all,
>
> I am actually interested in the automated install topic (currently taking 
> place in the other discussion, but I don't want to feed the troll so I'll 
> start a new one).
>
> Someone just mentioned Cobbler, and the fact that it's RH's baby. Is this in 
> any way linked to the recent acquisition of Ansible ?
> In fact, I never really understood what Ansible was, and does it have its 
> place in automated install? Can it replace Kickstart?
>

Cobbler was born inside of Red Hat but is now run at
http://cobbler.github.io/ versus the fedorahosted where it shows up
the most in google. Cobbler was written by the same person who wrote
Ansible but is not the same or linked to Ansible in anything other
htan that.

> As you can see I am pretty naive about the topic...
>
> Thanks,
>
> Benjamin



-- 
Stephen J Smoogen.

Re: Kickstart / PXE / Cobbler / Ansible

[Nico Kadel-Garcia]

On Thu, Jan 14, 2016 at 2:37 PM, David Sommerseth
 wrote:
> On 14/01/16 15:21, Loris Bennett wrote:
>> Hi Benjamin,
>>
>> Benjamin Lefoul  writes:
>>
>>> Hi all,
>>>
>>> I am actually interested in the automated install topic (currently
>>> taking place in the other discussion, but I don't want to feed the
>>> troll so I'll start a new one).
>>>
>>> Someone just mentioned Cobbler, and the fact that it's RH's baby. Is
>>> this in any way linked to the recent acquisition of Ansible ?  In
>>> fact, I never really understood what Ansible was, and does it have its
>>> place in automated install? Can it replace Kickstart?
>>>
>>> As you can see I am pretty naive about the topic...
>>
>> I don't know very much about kickstart
>
> As a rough crash-course  checkout /root/anaconda-ks.cfg on a freshly
> installed system.  If you want to do the exact same installation once
> more, you copy this file to a medium or web server and provide the URI
> to this file on the kernel command line before starting the installer.
> If anaconda picks it up, you'll have an automated install running instantly.

Really, you don't. "anaconda-ks.cfg" is the anaconda pardsed results
of the deployment procedure, and lacks many critical feautres of a
robust kickstart file for PXE or other common kickstart setups.

* The default installaiton labels partitions by the DHCP or otherwise
configured hostname, which is confusing on multiple hosts using the
same kickstart file.
* It comments out the disk configuration stanza.
* It includes distinct comments and layouts from
"system-config-kickstart" or other constructed kickstart tools.
* It does not correctly handle multple '%pre', '%post', or '%post
--nochroot' stanzas.

If you want to use a consistent kickstart, and have each published
host have a reference copy of its actual upstream kickstart file for
future reference, add this stanza to your published kickstart files
before using them.

%pre --nochroot
cp /tmp/ks.cfg /mnt/sysimage/root/ks.cfg

>
>
> --
> kind regards,
>
> David Sommerseth

Re: SL 6.7 Kernel headers misses typedef sa_family_t

[Antonio Querubin]

On Thu, 14 Jan 2016, Mark Stodola wrote:

It looks like sa_family_t has been morphing over time.  In SL5, it is indeed 
defined in linux/socket.h.  In SL6 I find it defined in bits/sockaddr.h.  In 
SL7 it continues to be in bits/sockaddr.h, but there is also 
__kernel_sa_family_t defined in linux/socket.h.


Try adding bits/sockaddr.h to your includes.


That probably should be .  From the sockaddr.h:

 * Never include this file directly; use  instead.


Antonio Querubin
e-mail:  t...@lavanauts.org
xmpp:  antonioqueru...@gmail.com

Re: Kickstart / PXE / Cobbler / Ansible

[Robert Benjamin]

Sir: Please remove my name and email address from your list. It is 
sent by error. Thank you.


On 1/14/2016 2:37 PM, David Sommerseth wrote:

On 14/01/16 15:21, Loris Bennett wrote:

Hi Benjamin,

Benjamin Lefoul  writes:


Hi all,

I am actually interested in the automated install topic (currently
taking place in the other discussion, but I don't want to feed the
troll so I'll start a new one).

Someone just mentioned Cobbler, and the fact that it's RH's baby. Is
this in any way linked to the recent acquisition of Ansible ?  In
fact, I never really understood what Ansible was, and does it have its
place in automated install? Can it replace Kickstart?

As you can see I am pretty naive about the topic...

I don't know very much about kickstart

As a rough crash-course  checkout /root/anaconda-ks.cfg on a freshly
installed system.  If you want to do the exact same installation once
more, you copy this file to a medium or web server and provide the URI
to this file on the kernel command line before starting the installer.
If anaconda picks it up, you'll have an automated install running instantly.

A more comprehensive guide on kickstart can be found here:



but am currently using ansible to
set up two administration servers for a test cluster.  My meagre
understanding is that kickstart is mainly aimed at the initial
lower-level installation (partitioning the disk, installing the base OS
and other packages, ...).

Correct.  Ansible is more for further automated setup tasks after the
core OS has been installed and is ready for the network.

Especially if you're playing with virtualization or containers,
cloud-init might be another useful tool to prepare images when using
image cloning.  In some cases it might be useful for bare-metal installs
too, but it isn't network based.  If 100% network capable setup is
required, ansible is a better alternative.

To start an install without anything else than a local network, PXE boot
can help out.  I've done that at home, that was a fairly straight
forward process.  Bascally you configure the dhcp server to provide PXE
details for computers booting of the network.  Then you need to
configure a tftp server which provides a boot menu/configuration and
boot kernels.  I did that without involving cobbler.  Cobbler might be
beneficial in some setups, but haven't dug deep into that.

How to get ready for network installs can be found here:

Re: Kickstart / PXE / Cobbler / Ansible

[Paddy Doyle]

On Thu, Jan 14, 2016 at 03:21:09PM +0100, Loris Bennett wrote:

> Hi Benjamin,
> 
> Benjamin Lefoul  writes:
> 
> > Hi all,
> >
> > I am actually interested in the automated install topic (currently
> > taking place in the other discussion, but I don't want to feed the
> > troll so I'll start a new one).
> >
> > Someone just mentioned Cobbler, and the fact that it's RH's baby. Is
> > this in any way linked to the recent acquisition of Ansible ?  In
> > fact, I never really understood what Ansible was, and does it have its
> > place in automated install? Can it replace Kickstart?
> >
> > As you can see I am pretty naive about the topic...
> 
> I don't know very much about kickstart but am currently using ansible to
> set up two administration servers for a test cluster.  My meagre
> understanding is that kickstart is mainly aimed at the initial
> lower-level installation (partitioning the disk, installing the base OS
> and other packages, ...).
> 
> Ansible on the other hand requires the machines you are managing to be
> already up and running and, normally, accessible via ssh.  Thus it seems
> it is a more fancy way of doing what kickstart can probably do in the
> post-install section.  However, Ansible works with 'playbooks', which are
> sets of 'plays', which in turn are sets of tasks to be carried out on a
> set of hosts.  You can run entire playbooks or just groups of tasks and
> you can also define roles, such as 'ldapserver' or 'dbserver' to bundle
> associated tasks together.  In general it seems slightly more orientated
> towards automated day-to-day management of multiple, heterogeneous hosts.
> 
> That having been said, I am no expert.

Nor I, but just a small note on our setup.

We use PXE+kickstart for a very minimal initial install.

Then, using a provisioning / configuration management tool we configure the
machine with the desired config, including things like:

- software repos and package installation
- configuration files
- user authentication (local users and/or LDAP etc)
- host and user keys
- network settings

We are currently using SaltStack mostly, and have used Ansible and Puppet in
the past. Other similar solutions include Chef and CFEngine, but I don't have
direct experience with them.

They each have pros and cons, depending on your exact local needs, or language
of preference etc.

There is of course the problem of how to initially connect to the
freshly-kickstarted machine, and there are multiple solutions for that depending
on which provisioning tool you're using.

Kind regards,
Paddy

-- 
Paddy Doyle
Trinity Centre for High Performance Computing,
Lloyd Building, Trinity College Dublin, Dublin 2, Ireland.
Phone: +353-1-896-3725
http://www.tchpc.tcd.ie/