Part 1 Chapter 12 of Canada's Hundred Days with Canadian Core from Amiens-Tumon, August 8th to November 11th, 1918. This is a LibriVox recording. All LibriVox recordings are in the public domain. For more information or to volunteer, please visit LibriVox.org. Canada's Hundred Days by John Livesey. Part 1 Chapter 12. French Scenes On the morning of August 8th, the first echelon of Canadian Core headquarters moved to Gentile, but already this was too far behind the lines and almost at once another move was made to Damoun, on the loose. In a ravine about a thousand yards south of the village, as had been plotted out by our intelligence long before the battle opened, was an enemy regimental headquarters, and here the core stayed a full week. As usual there were some elaborate dugouts, but not enough to accommodate all the staff, most of whom slept under canvass. This ravine winds among the folds of Chalk Hills, trending south to the Roy Road.  The tank had been working its way along the ravine when its career was stopped. Beside it are three graves. Artificers are busy repairing its shattered treads, and in an incredibly brief time it will trundle on its way again. From the upland is a wonderful sunset, painting the heavens the colour of blood. Upon the crest of the western slope, black against the glow, is the scarred outline of Hammond Wood, where a few days before our third division had a tough fight.  Our burial-parties are overtaxed. Descending the hill we come upon a lonely pit where a gunner stands silent beside his archie, for these moonlight nights high knee has a regular schedule of bombing visitations. He is glad to talk and confesses himself something of a poet. He produces a copy of verses, scribbled on the back of an envelope. Happy soldier, spinning rhymes beneath the stars, themselves his theme, and love of country and hate of the destroyer. We are dozing off in our tents, sunk three feet beneath the ground for safety from the flying shrapnel of these bombing raids, when on the silence a bugle rings out, a note weird as that of the coyote under a prairie moon. Lights out, lights out, passes the word, high knees coming. Sure enough, he is. But before we hear his angry insect hum, miles it seems above us, there comes the quick rattle of the archies, the anti-aircraft guns. As heads poke out, shafts of light, long beams of widest light, shoot up from a dozen unexpected quarters, searching the sky methodically for the bold intruder. They sweep the sky into fatagably. Some one with night-glasses cries they are below him, now they are nearer. They've got him. They focus on one spot and he stands out clear enough, a flitting, iridescent glowworm. The archies redouble their fire. We see the flashes bursting round him. His machine gun rattles back down the avenues of white light. They lose him and catch him again. Suddenly a series of dull explosions crump, crump, crump as quick as you can count. He is getting rid of his bombs. It is too hot for him. Soon his drone dies away in the east, but not before there have been more dull, thudding reports, distinguishable from all kinds of shell fire. It is seldom they get him. In the air the vertical plane is added to the gunner's problem, whereas on the surface his equations are confined to the lateral and horizontal. But the defence, especially the search lights, captured by us from the bosh, keep him high up, whereas bombing becomes a thing of chance, hit or miss.  He is going back to his base to tell his story of destruction. On a bare hillside and in a couple of hours he'll be back reloaded. But the air is chill and blankets warm. Not content with their brilliant capture of Zed Wood, recorded above, the French First Army are pushing on south of us, now well up to our right flank. They are putting on a little show of their own this afternoon in front of Roy. They have taken Caesar's camp west of the town and now seek to exploit their success from the south. Armed with a pass from General Demitz, commander of their fifty-sixth division, one has the privilege of seeing something of it under guidance of a charming French officer of intelligence. Roy lies low down in the valley and from the plateau on which we stand nothing can be seen but the smoke of bursting shells in its northern quarter, where already the French have established themselves in the railway station. The battle itself is in progress at our feet in the marshy tree-studded valley of the Arre, being directed against the strongly fortified village of Saint Mar-le-Trio. We can see nothing of it, save for an occasional rocket marking the progress of the infantry, signal for the barrage to lift, and for the angry explosions of enemy shells along the trench lines in the opposing plateau, where presumably are massed the French reserves. It does not matter. In these bright weeks villages such as this so recently impregnable strongholds are stormed every day. Of greater interest is the spirit of the French soldier, the poilou, from whose soul speaks the ardent voice of France. Our guide is explaining the difficulties of the attack up the valley, past concrete machine-gun emplacements hidden in the marshes. We hardly hope to succeed here, he says, but it is a demonstration innate of our advance further south. If we are wrong, soon a rocket goes up from the village itself. Yes, they have given us a tight corner, but what would you do? Someone has to have it. We have called him, Captain. No, he is only lieutenant. A simple soldier, monsieur, who at the outbreak of war was a wine-merchant in Burgundy. I had served my three years of course, and joined as a sergeant. Now I have charge of the intelligence of the regiment. You have very gallant men, he goes on.  We have been at it so long we are tired. Our hearts are sad, but now before us is the end and we will see it through. Alas! For the poor people of this country. In March I was in Mont-D-D-A, and the women of the town crowded round us. Are the boge coming? they ask. We do not know, but it is better you should move out. Then comes the question. What shall we take? What can they take? Their men and their horses are all in the army. There remains only the push cart and the wheel-barrow. They take next to nothing, and in a few days the boge have destroyed everything, everything, wantonly, where their shelling has not completed the ruin. On your way back go and see the ribs of Mont-D-D-A. We are standing on top of an oak-hip, observation post, built up by the Germans amid the trees on the valley slope. Below lies a shattered village and ruined church sent our in. It is horrible to see all this, one says, and to think that we in Canada have escaped scot-free only the lies of our men. Ah! he says, but is not sorrow a strength to the character, a completion of experience, shall we not emerge a stronger people for it all? We are in a trench examining a bayonet, a beautiful rapier-like piece of polished steel. How you bring your sense of art and beauty into everything, one cannot help remarking. Look at your camouflage, what art it is, suiting itself perfectly to the changing aspects of soil and landscape, while ours too often is a matter of rule of thumb. That may be so, he replies, but you have your admirable perseverance, to each nation its own qualities, to the hun that of the beast. Of a saddened countenance is a French soldier. The tragedy of war has transmuted the once merry fellow. They lack, too, the outward smartness of our infantry. But the spirit is there. On to the Rhine, we cry to one of them. He lights up at once. That is the perfect word, monsieur, he says with a grin. One takes away a sense of what the French army has suffered and endured. Compared with ourselves they lack deplorably all manner of material and equipment. Their guns worn out, ammunition depleted, their horses emaciated, and with few lorries for transport, the poilou himself a pack mule on the march. But after all these long years, when they have borne the brunt in defeat and in victory, their men are incomparable, their spirit unquenched. It is August 19th and we are back again in Dury, just twelve days since we left this sad and dreary village. Nothing but dust and troops and lorries. Occasionally through a tall gateway is the glimpse of an old woman, doubled under a load of straw. Much more rarely a child. One little estimate is open where they sell red and white wine of the sourest vintage. All the villages of this part of France are ugly. Built right out to the street are the stables and outhouses, blank walls pierced by inhospitable double gates. You enter your billet through what is essentially the backyard, a manure pile in its center and cart shed on either end. Back is the decent little house, two-storied, very old, weather-stained, sadly lacking a coat of paint and a rambler rose. You walk across through the inevitable tiled floor to the back. Hey, presto! What a change is here? A charming garden, stocked with good things to eat, fruit trees and flowers, and behind a hedge and a field rolling down into a green valley.  High gray blank walls, shuttered windows, smokeless chimneys and clouds of dust shrouding the passing transport. Beyond the village the landscape is bare, for not here are the nestling, red-roofed farmhouses of Old England. It is a communal life, dear to the French peasant heart. Madame may chat over the wall to her neighbor, knitting the wile and keeping an eye on the simmering pot. The French peasant likes company, and he sits of an evening in the village park, sipping his glass and swapping news with his cronies. Thus is explained the utter ruin the invader has ricked upon the countryside. His target is not isolated farms but densely populated villages, containing within their scant area all the rural population. Better for the French peasants if they had lived in scattered homesteads. We have been away a bare fortnight. When we return all is changed. Gossips and laughing children enliven the street. Dury has little to show of scars. Here and there the boge has left his mark, screaming bombs from out the night, or the devastation of a long-distance gun. But it has suffered in foreboding. Last spring the tide of battle lapped very close to its thresholds. At any hour the enemy might select its humble area for bombardment. All the bigger houses, the chateaux, are long-closed, their owners in happier climes. Only the village folk have clung to their village. They had nowhere else to go to their village and their poor chattels, their cow and their waddling geese. The good curer remains to watch over his flock and deplore the ruined tower of his grey old church. But now the foe is many miles away, and the village saved, saved with the wrecked city of Amiens. In those days we saw many villages in far worse plight. There was Domart, a ruin swaddled in dust, dust, dust everywhere, red dust from the brick of broken homes, bathing the passing lorries along the Roy Road. There was Marcel Cove, a cemetery of houses. Only the skeletons, instead of decent burial, loom white and gaunt against the sky. Constructed of century-old timber framing, these still stand after the tiles and plaster have melted into dust. Such stricken villages do not present the munificent ruin of the priests, et cetera. Nor are they a flat and disregarded desert like Nuvia St. Basque at foot of Vimy Ridge. But they are very horrible. There is something indecent about their stark ribs. At midnight of August twenty-one to twenty-second comes the moving order. Secret and confidential lorry, number so-and-so, will be at the door of your billet at five forty-five. No breakfast served in messes after six a.m. Destination unstated. On such occasion the Camp Commandant is the best hated man in the corps, for there seems a certain malignity in these midnight allurems. At last one was going to put in a good night's sleep to catch up needed arrears, but no, there will be little sleep this night, with the problem of squeezing a gallon of gear into a quart-pot. Treasured souvenirs must go into the discard. Once again on the move we discover we have a full day for the relatively short jaunt to Haute Cloak, south of St. Paul, and can spend some hours in Amiens. A year ago the joyous congregation of young officers on leave, but now deserted, empty streets echoing to the passing hoofbeat. A truly pious nation the French, a people of reverence for the fine things of life. Their piety today takes other direction than that of yesterday. It kneels at the shrine of an idea of France. In all their churches is to be seen the shining figure of Jeanne d'Arc. Their national heroine broods over them an idea that has triumphed in this war over material fact over four hundred and fifty centimeter guns. Every crossroad has its shrine, and in every little hamlet the village church stands a monument of ancient art and piety, the treasured storehouse of the community from generation to generation, enriched by free fancy. However dull the village street, there lifts out of its folia just slender, fretted spire, or maybe a hoary tower, sign manual of the spiritual life below. War has quickened that life. Not in vain calls the church bell to mountains and rivers. In no land is the beauty of sacrifice as well understood as in France. Thousands of these humble altars lie in ruin, more ruinous than the ruined villages singled out malignantly. It was not by his design that the great cathedral of Amiens escaped almost unscathed. Its topmost pinnacles are far below the level of the immediate hills, and yet for four months it has been the target of long-range guns and bombing planes. Draw a circle of a hundred yards around it and everywhere is destruction. The glorious Gothic West Front, still sandbag many feet up, is pitted with shrapnel. Good saints in their niches have lost arms and legs. It is a miracle that it has so escaped to be for generations to come a shrine for pious pilgrims who may see in its scarred but stately lines the symbol of the indomitable nation that kept alight through storm and ravage and woe the torch of civilization. Only an ecclesiastical architect can write of such things at every turn the layman exposes himself. But it is impossible to pass by Amiens' cathedral without catching something of its spirit and its meaning. The popular, the picture postcard, view is the West Front, with its irregular twin towers, its great rose window and all the lavish ornament of decorated Gothic. It is a fine example of that kind of thing such an impression is here deliberately cultivated, as might be that of a woman attired for the chief event in her life. But this ornate richness and luxury of treatment is not what appeals in the particular connection. Curiously enough, it is restricted entirely to the West façade, for the rest is art reduced to the finest simplicity of free-springing perpendicular columns and arches, delicate tracery, flying buttresses, and high-shouldering roots. Here and there this austere and chaste expression breaks out into rebellious fantasies of gargoyle and quaint grotesque, roughly carved from the solid block. The aspect one loves is the intimate view of the basilica from the foot of Rue Victor Hugo, a vista of grey stone and purple slate, an impression of devout, aspiring feeling that deliberately carries the eye unchecked and unencumbered by superfluous ornament up and up and up to the pinnacle of wonderful little Gothic spire superimposed upon the cross of the building, that from any other view it is not visible from the West front seems unmeaning and even absurd. From earth to the high Elysium is its message, and to pass thence into the square and thus confront the floored elegance of the West façade is to fall from heaven to earth again. The same pure and simple beauty is to be found within. Most of the old glass has been removed, and gone to is much of the guilt and tinsel that too often obscure and distract the noble lines of these buildings. The interior is reduced to its simplest values, without ornament, such as it was conceived and executed by its monk-builders. It is a house cleansed by war, like unto the people of France. There is little but the bare beauty of form and light, but the impression is of an immensity. The nave is subdivided by lofty shafts and bold arches, simple variations of the trefoil prevailing. Its surpassing beauty is due to these gracious lines and their high uplift to the vaulting of the ceiling. Wide untrammeled spaces and the clear sunlight streaming through the tracery of great unglazed windows give the impression of open skies and the wind upon the heath. Not here the mystery of stained glass, dim perspectives and glorious shrines, but the flinging wide of doors, the sweeping down of cobwebs. Back of the high altar, and facing the rich frescoes of the Lady Chapel, is a simple relief dated 1628, to the worthy memory of Johannes de la Grange, one-time Episcopal ambassador and cardinal.  Another slab perpetuates the charity he established for the poor children of the diocese, a worthy man, this Archbishop of Amiens, and a proud, without doubt. In and about this great temple, Canadian and Australian soldiers reverently wander. They see in it something mystic, the pledge of their victory, its vast, echoing spaces peopled by their comrades who have laid down their lives. Against this pile of grey stone wherein lies enshrined the feeling of all the ages, the Hun hurled his implacable hate. In its drive of August 8th and 9th the Canadian Corps captured half a dozen 5.9 inch naval guns with a range of 25,000 yards, and there is reason to suspect some of these were the very long-distance rifles that sought to destroy the cathedral of Amiens. Of direct hits possible to identify, two at least are of this caliber. One destroyed the northeast chapel of the ambulatory, another the organ platform under the rose window, but the organ, a famous piece, had been removed to the crypt. Amiens Cathedral is now safe. Yet another bond was thus knit between the peoples of France and of Canada. Over the great altar hang the flags of French regiments, and among them the stars and stripes. The ensign of Canada might here well find a worthy resting place.


Epigenetic clocks are one of the most effective tools we have for estimating biological age. They can be extremely useful in figuring out whether a lifestyle choice or therapeutic intervention increases or decreases biological age compared to chronological age. For that to really make sense, epigenetic clocks should also be good predictors of things like longevity and mortality. In other words, if an epigenetic clock says you're biologically younger, that should mean you'll live longer.


All right, we'll go ahead and get started here. Hello everyone, my name is Terry Bowling. I am on the REL product management team for Red Hat Enterprise Linux with Red Hat. And my area of focus is REL automation and management. How can we make REL easier for you to manage and configure? And of course, all of the things that we do also translates to Sintos and Fedora. And with me is Pavel. Would you like to introduce yourself? I'm Pavel Tsahina. I am the developer of the system roles project. And I'm a senior software engineer at core services at the REL business unit at Red Hat. So today, we're going to talk to you and educate you about Linux system roles. And so the overview of this talk will be the overview of the system roles. We're going to give you an introduction to two examples, the network and storage roles. Because those are our two roles that we're getting a lot of feedback that those are some of the most commonly requested or needed types of automation when managing REL. And then Pavel is going to show you some examples, some demos of how to use it. And then we'll talk a little bit about some of the common role challenges. So the reason we're here, I spent about 14 years as a sysadmin for a few different companies. So I've kind of been there with you, managing, configuring operating systems and taking care of things when they go bad. And back in the day, I wrote a lot of really bad shell and Perl scripts. I was very proud of them at the time, but I pity anybody who had to take them over after I left and they got the job done. They needed, they helped me do what I needed to do. But I can completely relate to these examples where we need to do something. We write some clever script and in Perl I loved Reg X and I did a lot of horrible things, but it was fun. Some of them were wicked cool. I didn't always remember a year later why I wrote some of it, but it worked at the time. But as things change, stuff broke. And we see that all the time with REL, the transition from REL four to five to six to seven and all of the rapid changes that happen in Fedora, things change and your scripts need to be maintained. And of course, the cycle is rinsed and repeated. So one of the questions we're asking ourselves is how can we make this easier? And as things change, how can we Red Hat and the Fedora ecosystem, how can we take on some of that technical debt so that we maintain this so that you don't have to? And so what we have, our goal is to provide a collection of Ansible rules that function as a consistent configuration interface to REL and Fedora. And when I say REL, you can insert Sintos there, but usually I'm usually saying REL and Fedora most of the time so I'm not ignoring Sintos. And how can we ensure that they're compatible and tested on a regular basis with Fedora, REL seven and eight and future versions? And some of them are also compatible where appropriate with REL six today. And ensure that they're constantly compatible and tested as things change. And so we're abstracting configuration from implementation. And what I mean by that is as tools and utilities change, networking is a great example. Your application needs an IP address and maybe a bonded pair or multiple aggregated network interfaces. Lots of times our CIS admins don't necessarily care about bonding versus teaming or init scripts network configuration versus network D versus other things in the ecosystem like system D network D or maybe some future crazy, wild idea that somebody dreams up that turns out to be awesome. How can all the CIS admin cares is this team is asking me to stand up this database and it needs bonded networks. All I care about is the IP address and multiple NICs. That's all I care about. I don't wanna care about all the utilities, all the low level technologies. I'm overwhelmed. I've got too much to do. There's too much to learn. I can't absorb it all. So we put that technical debt, the community. We put that technical debt on users. So we're abstracting this. So we're giving you a simple way to describe, I got an IP address. I want a bonded pair. Just make it so. I don't care about the details. Just make it work so that I can go to lunch with my friends. And so that's what we're doing. And it's also critical that this is maintained by Fedora and RELL engineers. We couldn't just go to Ansible and say, hey, do this for us because they're not experts at the networking stack. They don't know what's going on in networking upstream and community. They're experts at designing an automation framework. So we need our RELL and Fedora subsystem engineers need to be the experts of that subsystem. And knowing when things are being developed and how. And so we're working with a number of different teams to develop this and put in automated CI testing in Fedora. So that as these change and evolved and new functionality gets added, we can maintain that automated testing against RELL 7 and RELL 8 and future versions. So what we have today in Galaxy and on GitHub, we have this Linux System Roles project. From that, we publish that in Galaxy. So if you're an existing Ansible user, you can simply type Ansible Galaxy install linuxystemrolls.network or .firewall or whatever, whichever one you want. We also package them in Fedora as a Linux System Roles RPM package. And in RELL, they are packaged as RELL System Roles RPM package. And the reason for that is we have use cases where we need to make these accessible like from the DVD ISO image and things like that because people might want to do automation where they don't necessarily have network access. So not everyone is quite accessible to the internet and able to use directly from Ansible Galaxy. So we're looking at a variety of other things like Automation Hub that the Ansible team is working on and different things like that, providing multiple ways to access it. But the versions that we package is what we can say this is the tested version that we're packaging and supporting for enterprise use, but the same team is working on the same stuff and the Fedora CI testing is doing a lot of the testing. So the stuff in Galaxy is really good too. But the stuff in Galaxy, you're gonna be seeing change at a faster rate until we package it and ship it, for example, into RELL. So multiple ways of accessing it. And so what we provide today is network, storage, SELinux, TimeSync, PostFix, and KDump. With RELL 8.1, we started providing a workload role for basic SAP HANA configuration as well as free IPA identity management is also available in Galaxy. And I think, where's Thomas? I think we're gonna be shipping that in RELL soon. Yes? Oh, it is an 8.1. Awesome, thank you. I didn't realize we were actually shipping it. So my apologies. Yeah, so free IPA, if you're not familiar with that, it's a really awesome identity management system. I think they have a whole another presentation. Thomas, you're gonna be presenting on automating IDM, right? So look for that session. He'll be using these as examples. And some other things that we're actively working on, scoping out requirements for our firewall. We already have a proof of concept firewall role in our project in Galaxy, so you can try it out and test it. We're making some revisions to it before we declare it stable, or before we start shipping it as an RPM package. And then additional application workload roles for Microsoft SQL server and things like that. The logging role will help you stand up or standardize logging profiles. So if you need high performance logging or lossy logging use cases and setting up a centralized RSS log server or setting up rel to log to an elastic search, it'll help you take care of all of those different use case scenarios. So lots of stuff, kernel bootloader. We got a lot of stuff we're excited about that we're working on. So you'll see those gradually appear in Galaxy and Fedora. And then I think we have two or three lined up for the rel 8.3 release. So we're pretty excited about the new stuff we're working on. So that's the general overview. And I think now I'm going to hand it over to Pavel and he'll take over for the demo. Thank you for the introduction. And as Therese said, the main feature, the control. Sorry. The main feature of Linux system roles compared to maybe some random roles that you can find is supporting multiple releases and hiding the changes away from you. So how exactly are we doing this? So one class of changes is just simple, like package renames, renames of configuration files, renames of services, those are easy enough to handle. But then we have more substantial changes like change of the complete implementation of a given functionality may be replaced by something else. And those implementations of a given functionality we call providers. And so our roles support multiple providers when appropriate. Some examples, canonical example is our time sink role. Note that it's not called crony role because it abstracts away the details of crony and it supports both NTPD and crony. So we have two providers for the time sink role and they are configured in the same way. So you put the same variables and you just specify the provider and it writes out the crony or NTPD configuration as appropriate. Another classic example is network role when we can configure networking via the old init scripts or network manager. Logging, we have just one provider, RC slog, but it's prepared to accept other providers but I'm not claiming that we will ever support it but the possibility is there. And the providers, as I said, implement the same interface or at least a common subset of this interface because of course not all the providers will support all the possible features. So now I will introduce some of the roles. I will not introduce all of them but I will select a particular subset. First one is time sink, which is a medium complexity role, let's say. And the interesting thing about time sink is that it supports those two providers. So it accepts a time sink NTP provider variable which can be set to NTPD or crony. And then the rest of the configuration is same. And what happens if you don't specify this variable then it chooses an appropriate default for the given system. If no time sink service is running, if there is a time sink service running it respects your choice. And so for other versions of REL6 it would be, the default would be NTPD but for newer versions of REL6, REL7, NTPD8, NTPD8, the default would be crony. So this is the example playbook for complete application of the time sink role. Then networking, this is one of the most complex and I would say the most useful roles but I will show just one slide about it because there's another trial by Till on Sunday and I also talked about it. We talked about it the last year. So as I said, the network role is the example playbook. The network role also supports providers, network manager, and init scripts. The default for REL6 is init scripts for newer releases. It's a network manager. And what is important is the network role actually doesn't manage direct interfaces by connection profiles, which are a concept in network manager and init scripts have the appropriate scripts which are mapped to connections. It accepts a list of connections and the feature it can set are many. One of them is runtime state up or down. Persistent state that means connection is present or absent on the system. It supports Ethernet devices. It supports IP protocol configuration both for REL6, automatic via the HTTP or static like here. It supports bonding and teaming. Bonding is more official, teaming is let's say interview. It supports VLANs. Here's actually an example of bond. We configure bond into one member interface of the bond. It supports VLANs. It supports bridges, infinite band, make VLAN. So, an example, as I said, list of connections. This is a bond with a defined IP address and the member of the bond. We can say what interface name should the connection be bound to if this is not equal to the connection name. And we applied the network with those variables. So now the storage role, this is quite new, so I'm going to speak about it longer. The principle is to simplify local storage configuration. This means providing concise model to describe the storage layout. It means the model of variables accepted by the role. Also provide reasonable defaults. Now in Fedora, you have a default file system of XFS and the default storage layout is LVM. But this may change. Maybe in the future it will be Stratis. So we don't require the users to specify what they want and we apply the default from the system they are running. But of course, Stratis and LVM would have to be managed by the same interface to have this consistent experience. So this then provides a requirement for this concise model because it has to be abstract enough to cover multiple implementations. Also, this is related to the endless non-essentials details automatically like creating a partition or not. It chooses, if you don't specify it chooses a default which currently is to not create a partition but create LVM directly on the disk to simplify the layout, but this may change. And it reuses the existing storage management logic. What does it mean in practice? It uses the Blivet library which is also used in the Anaconda installers of the layout and the details should be the same as provided as created by the installer. Unfortunately, this is one consequence. The Blivet library is not available at the required version in L6 so we can manage only L7 and L8 and of course, recent versions of Fedora. So now some examples. Simple example, we have an example playbook which creates a file system directly on the disk without volume management. So we have volumes variable which says that we want to mount it as slash backup. The disk should be SDC. And the file system tab is commented out because it chooses a suitable default which is XFS. Now what about, this was just a whole disk. Now what about volume management? So for this, we are getting back to the consistent configuration. So we choose an abstract model. We have two layers of configuration. We have pools and inside the pools we nest volumes. And for LVM, pool is just a volume group and volume is logical volume but for other volume managers, the terminology may be different but we will abstract it in the same way. So LVM is for pools, LVM is default and actually the only supported one right now. So we create a volume group on those two disks. And inside the volume group, we create the volumes. We create two volumes with a given size. Again, the file system type doesn't need to be specified if you don't want. And we mount them and we actually also configure them in FSTAP so they are mounted on boot. So this is all handled by the role. We can provide, if needed, we can provide the file system type explicitly so if you want, you can make sure it is X4 if there are different changes. You can provide X4, whatever is supported on the system. You can set some file system label, file system create options or mount options. Those will be, of course, file system specific. So when you do this, you must make sure that you understand the appropriate options for a given file system. So with the status now, we have a stable version released already in the Galaxy version 1.1, I believe. It's included recently in the 8.1. What is supported is what I showed, whole disk and so with single partition, basic LVM support. And what will we support in no particular order is encryption and the rate LVM interventioning because those are just the classical LVM logical volumes. The multi-path, also LVM rate in addition to MD rate and video compression and deduplication and possibly a host of other features like other volume types like strut is, if there's demand for this. So now about some challenges in the storage role. So I will first speak about the most important one because even if the storage role supports what you need and supports the system that you need and has a nice and logical and abstract configuration layout of variables, if it happens to destroy your data, you will still probably not be very happy with the result. So the most important challenge is not destroying your data. This was actually quite a challenge because the role doesn't remove volumes which are not specified in the variables. But what about conflicting volumes? If you have a volume already on the system and you create, you specify that you want a volume with the same name but a different for a system type and we cannot convert from XFS to X4 or vice versa. So the role would have to delete the volume and recreate it. Or let's say you, by mistake, you give it a disk or there's an existing partition or existing file system and you want to create LVM on it or vice versa. You don't want the disk to be wiped in this case. Of course, detection is not 100% reliable in those cases but at least when we can detect it, we don't remove it because we have a variable stretch safe mode which defaults to yes and which tells the role to not do such possibly unintended and unsafe operations. So this prevents removing and creating existing objects. But it doesn't protect again against intended removal because if you say that you want such a volume to be absent, it will remove it because in this case, it's presumably not a mistake. It's what you asked for. Another challenge is for those are like challenges more for the future development. So those are stuff that people would probably like to have but they are kind of hard to implement. One is automatic device name where one wants to create a file system on LVM. One needs to supply mount point and also the logical volume name. So we want that is to consider not having to supply the logical volume name and having it deduced automatically via some, let's say default from the mount point name. Also automatic size if you want to use the full size of the disks it shouldn't be necessary to specify the size. Another is automatic disk selection is unused disks. You shouldn't be forced to specify the disk by the names which can be even changing but it should be possible to just say that you want all the disks or the three disks and the role would create the layout on all the disks. And also size specified as pretend percentage of the total space. Why they are changing because it's easy enough for new deployment but then it's question what to do if the system changed like if we choose to do LVM on all the disks and then you add a new disk what should the subsequent application of the role do when there's already this volume group. So we are thinking that the key is to preserve the current configuration when it's already there and not adding new disks. Also for percentage-based size of course we cannot support it as percentage of the free space because if we say 100% of the free space, next time there will be no free space and the next time would use zero or any other percentage it would be probably indeed. This means that we have to specify the percentage of the percentage of the total. So now I will do a demo. The objective of the demo is to configure VM so that it has one more configured network interface. I will set a large empty on this interface. I will create a VM. I will access a disk over this VLAN. I will create a LVM on this disk and mount geological volumes. I will export them over NFS and I will enable firewall and the NFS must be working when enabling the firewall. But I will use that and I will actually use a reader because the network is too slow here. So let me show you the playbook. So can you read that? Does he need to make the font larger? Okay. Bigger, well. I'm afraid this is the biggest that extends up first. We do have all of this in a GitHub repo so that you can access it later. The link is at the end of the slide deck. So I'm gonna show you the assumptions for this example because I created an Iskazi target listening on the host. And I will not show how to do this because I don't have time. I will really show only the configuration of the virtual machine. So it uses some variables which tell to which Iskazi server to connect and what directory is to export. And first of all, I create the network configuration. So I set up the Ethernet interface with the large MTU. I could bind it to the interface, the profile to the interface via the name but I don't need to because the name is the same. I could also bind it via the MAC address. I configure an IP address on it and I configure a VLAN on this Ethernet interface. So I specify the parent which refers to this one. VLAN ID and also an IP address on the VLAN. Then the Iskazi initiated configuration. For this, we don't have a role yet. So I do it, let's say, manually using standard Ansible modules. I start the Iskazi DEMON. I make it connect to the Iskazi target. And this provides the name of the disks that it will create. Finally, I use the storage role to create the volume group on those disks. So the storage pool, the volume group is called export-vg and it has two volumes shared with a given size, with a given mount point. And users, I change the file system type here and also with a given mount point. I then make the directories word-readable so we can access them over NFS without worrying about authentication. And I export them via OASIS roles. This is our sister project. We don't have a Linux system role for NFS exporting so I'm using this one. This can be also obtained from Ansible Galaxy. And I'm sharing those two directories to the VM host. And finally, I'm using the network role, sorry, the firewall, also part of Linux system roles to enable the NFS service and to enable firewall D. We are applying the whole playbook. I'm doing the recording because with the network here, I found out it's too slow. It hangs at installing packages and it has to install packages multiple times. So the networking at this time has been already applied and it tested the connectivity. It does it every time because you may have changed your management interface. Now we're setting up the iSCSI initiator. And now we are applying the storage role. This is complex role, so it has lots of tasks so it will print lots of messages. So now it finished mounting those file systems and now we are exporting the NFS directories of NFS and finally, we allow NFS on the firewall and we exported those NFS shares. So here I'm on the virtual machine host and I'm mounting from the VM this one directory, the export share directory. And I showed that one can see the file, the test file that I created in this directory. Now I will show how it looks inside the virtual machine. So those are the network interfaces. You can see the VLAN here, ETH1 with the NTU. Also the VLAN with the appropriate IP address. I will show the configuration of the devices, of the disk devices here. You see the disk with the two logical volumes mounted as those two mount points. And finally, I will show that this is really the iSCSI disk because this is a utility which shows the iSCSI properties and you see it's indeed iSCSI. And to demo, I will skip this one. We don't have time anyway. And also the author of the login log run for church couldn't come to death conf. So how many of you consider using learning system roles now, not everybody? And how many of you consider are already writing unstable roles or consider writing unstable roles? I see definitely some people who wouldn't consider Linux system roles. So at the end, I will provide some notes about implementing unstable roles which are not specific to Linux system roles. So even those who implement their own roles maybe can learn something. So the challenges mainly revolve around respecting the previous setting, the previous state of the system. And I'm now speaking about actually interface challenges because we want to provide a stable interface. This means that we shouldn't change it because if we provide a way to hide the changes in the underlying system, but we change the role we create the same problem again. So we have to design the interface in a stable way. And so those are interface design changes. For implementation, we can always change it if we respect the previous interface. So about respecting previous setting, this is actually interface question. Whether we want to declare complete state or only to declare changes to the system. Let's show some example using the ACLinux role which I have not shown but it's simple enough. It can set standard booleans. The question is whether it should, when you list the standard booleans, whether it should only set those booleans and to drop all the previous modifications to a set a system to a clean state or whether it should just add this one boolean and keep all the previous ones. So let's suppose we would choose to drop all the previous modifications and only set this one. So we have an example of a Samba playbook which sets one boolean for Samba. But now let's suppose we have also an FS playbook which sets some boolean for NFS. And now we want to combine the two playbooks or render them for my master playbook or apply the two to the same host. What happens? Here we just clubbed the boolean here. So for this reason, at least by default, we in those cases always preserve the previous state and only apply the changes to it. Hey Pavel, we're almost out of time. Could we ask the audience if they have any questions and get their feedback? I think so. So yeah, does anybody have any questions? And then if we have time, we can go through a little bit more. Yes? Oh, of course. Because each role has a... Yeah, he was asking, is there a place where all of the variables and input parameters are documented? Do you want to take it? So each role has a readme file which you can see on GitHub or it is reproduced on Samba Galaxy and it's also included in the package. Also, it's formatted as HTML so you can see what the role does and what variables it supports. In the storage roles, you'll mention some feature about automatically picking drives and so on. And isn't that dangerous if you want to run a role multiple times? I mean, they are supposed to be idempotent, right? So like if I run them a second time, they shouldn't change anything. But it seems like they would always grab the next two available disks and so on. Yeah, that's a good question and that's why I elicited among the challenges, let's say the challenges or challenging features. And I think we think that the right answer is only to be able to say that you want all three disks and then on the next run there are no three disks but of course the volume group is already there so you don't need to do anything. But that said, if the volume group was already there, even if we picked only one of them, the second time as the volume group is already there, it will not modify it. That's what I mentioned. We want to make sure that the second time it runs, it doesn't do this automatic detection because it already has something and it's satisfied. So in this case it would see that like the mountain point that is associated so that drive already exists and then it would leave it alone. Yes, yes. Okay. Yeah, do you want to answer that? So the question was when you use the role statement in the playbook, it exposes all the variables to the whole playbook run and how safe it is, is it? And whether we should not use the include role. But the answer is that that's why the role variables are prefixed always with the role name to at least reduce the possibility of accidental collisions. But I'm afraid that the include role statement also keeps the variables, it doesn't? It's isolated. But if you use import role, it's like roles. Import now, include. Okay. There's a difference. Yeah, so it is definitely then safer to use include role, but we are working under the assumption that one would use the role statement and so they should be safe even for this. Another question? Any other questions? Yes, sir. So you just showed us Time Sync supports NTPD and Chrony 2. Do you plan to support system D, Time Sync D also? I don't think so. We do not yet support system D, Time Sync D, do we? Well, we don't support it definitely right now, but I think it depends on the demand whether we will support it. But right now we don't have any specific plans to do it. So if that's a feature request you would like to ask or request you can go to our GitHub repo and open an issue and any feedback that you have to share, anything that you would like out of these, we'd love for you to open an issue on GitHub or a bugzilla at bugzilla.redhat.com and let us know what you need out of them. If they don't meet your needs, we're very, very interested in your feedback.  Yes, sir. Yeah, we have a few basic examples. So the slides will be made available as a PDF and at the end is a link to our GitHub repo where there is a devconf demo folder and it includes a couple of different demos right now. There's one that uses them as an example for setting up an image builder node and then Povls will be uploaded later today, I think. It's already there. Oh, it's already there. So we have a few examples. We're also looking at, for those workload examples, we want to have like an overall end-to-end solution playbook that demonstrates using these to set up, for example, Microsoft SQL Server and taking care of like all of the different things you need to take care of. So we only have a few basic examples right now but over the next year we expect to have multiple. Also, you don't need to use all the rows at the start. You can start one by one because right now they are pretty independent. Yes, sir. Yeah, the question is, can I specify the block device by UUID or by, yeah, by like the PCI bus path? Do you want to answer that? Some of the methods are supported but I'm not entirely sure what is supported and what is not supported. But at least I think the UUID links are supported but it needs to be the device UUID button and not the UUID of the far system. Because there are, yeah, this one, okay. Yeah, actually, so not today but that's one of our goals. So for example, as a database administrator, the storage team gives me a new 100 gigabyte LUN or a terabyte LUN and all they give me is the WWID or the worldwide name or whatever you want to call it. And so how can we provide you multiple ways, both for networking and storage, to have multiple ways of expressing the device that you want to use. So for storage that might be the Linux blocks device name, might be the multi-path name or it might be the WWID that the storage array presents and then let the role figure out the multi-path names and everything so that you as an admin don't have to worry about it. You just plug in the WWID, hit go and it just takes care of that for you. So that's one of our goals and aspirations is to require the user to only provide us what details they must provide or want to express but not require you to specify all the typical default values. Let's assume recommended defaults so that you don't have to express all the details unless you want to. You have the power to express more details but otherwise just give me the WWID and I'll just get it mounted for you and take care of the file system for you with the defaults. Does that make sense? Anyway, I'm sure some of the links under slash devs, by something I supported but I'm not exactly sure right now which ones are supported right now so at least some of them are definitely supported. I just wanted to say something if we're ready to wrap up. Oh, just a cool thing. Okay.


This is Blake Williams coming from Chicago and he's presenting a case of up gaze restriction. Hello everyone, I'm Blake Williams coming from the University of Chicago. Thank you for having me this morning. I'm gonna be talking about a case of up gaze restriction. So we have our patient, ZW. He's a 42 year old male who presented to the emergency department with a two month history of right sided, initially in then bilateral numbness and weakness and a three day history of difficulty ambulating and worsening numbness. His past medical history is significant for a developmental delay, it was unspecified but he had muscle tenacity in the neck and back as an infant, as well as congenital right sided ptosis. He's had a number of surgeries in the past. He had a right ptosis repair with frontal fixation in 79 followed shortly by a strabismus surgery for a right up gaze paralysis and he also had a negative cardiac cath which was part of the workup for his diffuse numbness.  He had been drinking a few beers a night. He's single and worse with his father. No family history of neurologic or ocular diseases and he has a history of coronary artery disease and MI in his father. He has no known allergies and has been taking aspirin 81 since the cardiac workup shortly before he presented. For his hospital course, he initially presented in June of 2015 at an outside hospital for this weakness and numbness. A head CT on June 1st showed ventriculomegaly, predominantly left sided. He got an MRI of the cervical spine without significant findings, CTA was normal and his diagnosis was congenital hydrocephalus and discharge on aspirin. He was admitted about two months later on July 31st with worsening numbness and recent instability. A RIPID MRI showed stable hydrocephalus similar to the outside imaging. Neurology and neurosurgery were consulted. No intervention was indicated but then the next day it was noticed that he had bilateral up gaze restriction that was new and so ophthalmology was consulted. On ocular examination, that visual acuity was 2070 corrected to 2020 pinhole on the right, 2020 on the left. Pupils were symmetric and equally reactive. Full visual fields, pressure was 13 in each eye. Then the interesting findings were on extroocular motility. He had a right exotropia with inability to look up or down. He adducted on up gaze and abducted on down gaze. While on the left eye he just had an up gaze restriction and he adducted on up gaze. And then the very interesting finding was that he had a convergence retraction nystagmus noted on up gaze and it took a second examination by ophthalmology to confirm this. This is not the patient that we saw we weren't able to get pictures of before he was discharged but this is pathenomonic for the condition that he had. Significantly you can see when he has an up gaze restriction as well as a few other findings which I'll go into. So I wanted to show a quick video of the convergence retraction nystagmus. Actually, what we are seeing is convergence retraction nystagmus but you can't really appreciate the fact that the eyes are actually retracting. But this is what convergence retraction nystagmus looks like from straight on in somebody being asked to look up. Now looking from the side as she's being asked to look up you can see the eyes actually retracting in the orbit in this example of retraction nystagmus. So I tried to get a video on my iPhone but it was not nearly as good as that. Okay, for the rest of the physical exam we had a portable float lamp and he had some minor poteosis in the right eye some blufferitis in the left eye but basically everything else was normal. Lenses were clear, he had cup to disc of 0.4 normal dysmaculin vessels in the retina. This is taken from the neurologist, their physical exam. No cranial nerve exam finding except for the eye exam and on the sensory exam he had decreased sensation bilaterally in the lower extremities and hands and then also he had a narrow-based slow gait. So to recap, we have a 42 year old male with a two month history of numbness and weakness who presents with gait instability, worsening numbness and up gaze restriction with convergence, retraction nystagmus. So we got a number of studies and everything was largely normal. CBC metabolic panel, ToxScreen, they did a myocene agravus panel, copper was normal, B12 normal, CRP was less than 0.1 and no abnormalities on the lumbar puncture either. So this is the MRI that he got just showing diffuse enlargement of the lateral ventricles. The ventricular megal is more pronounced on the left side than the right but this was stable compared to the outside imaging and then just another view showing the ventricular enlargement and there are no other abnormalities seen on those scans. So what is the differential diagnosis of an up gaze restriction? There's a long list but basically the top two or three will be seen in the vast majority of cases. The first is dorsal mid-brain syndrome or perinode syndrome. Also progressive super nuclear palsy which presents similarly to Parkinson's disease and then a few other rare ones which I could not find much information on. In terms of other imaging, a CT cisternogram was recommended by neurosurgery but they actually didn't do it at Loyola which is the hospital I was at. They did an MR sign, showed no CSF flow, was appreciated in the third and fourth ventricles or the cerebral aqueduct was a minor flow at the foramen magnum but since this hydrocephalus was stable compared to before they didn't think it was a huge problem. So he was diagnosed with dorsal mid-brain syndrome, likely secondary to hydrocephalus and I already kind of went through his work up. So dorsal mid-brain syndrome is also known as perinode syndrome, sylvan aqueduct syndrome, pre-tectal syndrome or corbosalus L. schnig syndrome. There are five main criteria for diagnosing this syndrome. Basically clinical syndrome characterized by a cluster of eye findings and with movement abnormalities and pupillary dysfunction. The first of which is paralysis of up gaze which was kind of alerted us to his condition. Vertical palsy super nuclear, so the doll's head maneuver which is more of a reflex is preserved early on but eventually all upward gaze mechanisms fail. Second is pseudo-argyllarobbertson pupils. As you know, Argyllarobbertson is seen with syphilis but the difference between this finding and actual Argyllarobbertson is that in perinodes the pupils are mid-dialated and in syphilis they're very small. Third is convergence retraction nystagmus which is virtually pathodendemonic for perinode syndrome. Fourth is eyelid retraction also known as Kalei sign which we see a lot in thyroid eye disease. And finally conjugate down gaze in the primary position, the setting sun sign which gets its name from seeing the sclera and the patient is looking down when they're trying to look straight ahead. The main, main cause of perinode syndrome is pinealoma that's the correct board answer. This shows a large pineal gland tumor pressing on the dorsal midbrain but some other causes include other brain tumors really any compression of the tectum. Hydrocephalus especially after shunt failures it was thought that this patient's hydrocephalus caused his perinode syndrome. Other cause of multiple sclerosis, vascular lesions, myasthenia can mimic a vertical gaze palsy and uncle herniation. So in terms of epidemiology there are three main groups of patients who present with perinode syndrome the first of which is a young patient with a brain tumor of the pineal gland or pinealoma which is most common. Also women in their 20s to 30s with multiple sclerosis can present with this and finally older patients following a stroke to the upper brainstem. For pathophysiology, perinodes results from an injury to the dorsal midbrain or the tectum specifically compression or a scheming damage to the mesencephalic tectum and it includes the superior colliculus which is adjacent to the ocular motor and edginger lesion nuclei. I wanted to show some anatomy just to highlight the proximity of the pineal gland to the superior colliculi and obviously if you get enlargement of the pineal gland through a tumor you'll get compression of the area and dysfunction of the superior colliculi. And then this is just to show the control centers for horizontal gaze which is the PPRF or Pontine Paramedic Articular Formation as well as vertical gaze which is the Rostral Interstitial Nucleus of the MLF and you can see the horizontal gaze center is very close to the Abusin's Nucleus and the vertical gaze center is very close to the ocular motor nucleus and it just helps, if you help visualize that you can remember the association between the two. Treatment and Resolution. Treatment is primarily directed towards the etiology of the dorsal midbrain syndrome through a workup including neuroimaging is essential. He got the MR sign to evaluate his flow. The eye findings generally improve over the first three to six months and if they don't improve after that time it's unlikely that they will. And if the cause is from acute hydrocephalus especially shunt failure, if you correct the shunt failure and correct the hydrocephalus they should get rapid resolution of symptoms. So back to our patient. Given his stable hydrocephalus and the crinicity of this condition no further intervention was recommended at this time by neurosurgery and he was planning to follow up with ophthalmology and neurology and clinic in a few weeks and hopefully he would have improved. Then I did a quick literature search. It's very difficult to find anything on dorsal midbrain syndrome since it is so rare. I was only able to find this paper from 1990. This author kind of put together 206 patients with the syndrome and the most common sign is pupillary abnormalities. 96% of the patients had that. I just think it's interesting that only 34% had the classic convergence retraction nystagmus which is quite rare to see but if you do see it you can nail the diagnosis. Then for etiology it's most commonly hydrocephalus 39% but also stroke and turmeric can cause it as well. And it had mentioned in this paper that there was a large amount of sister circuses going around with these patients so that might have made the hydrocephalus more common than pinealoma because more recently I've read that pinealoma is the most common cause. Here are my references. Thanks for having me and any questions?