I dont know if i am missleaded but it seems to me that the cron type does not accept names with a ''.'' in it ? I tried to add a cron with a name cron1-$domainename and it does not accept it. If i remove the ''.'' in the domain it work. I am using .22.3 anyone seeing the same behavior ? If yes i will fill it as a bug. -- Cordialement, Ghislain ADNET. AQUEOS. Attention ! Toute demande de support ou commande de domaine par email sera refusée, pour cela utilisez https://support.aqueos.net. Pour tout contact nos coordonnées : http://www.aqueos.com/aqueos-services-informatiques-societe.php Fax: 01.72.70.32.66 _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
ADNET Ghislain wrote:> I dont know if i am missleaded but it seems to me that the cron type > does not accept names with a ''.'' in it ? I tried to add a cron with a > name cron1-$domainename and it does not accept it. If i remove the > ''.'' in the domain it work. I am using .22.3 anyone seeing the same > behavior ? If yes i will fill it as a bug.This isn''t a puppet issue, or even a cron issue per se, but a run-parts issue. From the run-parts manpage under Ubuntu (Debian is the same) If the --lsbsysinit option is not given then the names must consist entirely of upper and lower case letters, digits, underscores, and hyphens. If the --lsbsysinit option is given, then the names must not end in .dpkg-old or .dpkg-dist or .dpkg-new or .dpkg-tmp, and must belong to one or more of the following namespaces: the LANANA-assigned namespace (^[a-z0-9]+$); the LSB hierarchical and reserved namespaces (^_?([a-z0-9_.]+-)+[a-z0-9]+$); and the Debian cron script namespace (^[a-z0-9][a-z0-9-]*$). You could either modify your host''s crontab configuration to execute run-parts with the --lsbsysinit option, or make use of some other system for creating these files with the cron type, eg by substituting a "." for a "_".
> > This isn''t a puppet issue, or even a cron issue per se, but a run-parts > issue. > > From the run-parts manpage under Ubuntu (Debian is the same) >but a puppet name cron { ''mydomain.com'': hour => 5, command => ''ls -la'' } the name is only a puppet thing so what you told me seems strange no ? -- Cordialement, Ghislain _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
> but a puppet name > > cron { ''mydomain.com'': > hour => 5, > command => ''ls -la'' > } > > the name is only a puppet thing so what you told me seems strange no ?I actually misread your original post slightly. However, reading through the source for cron.rb: newparam(:name) do desc "The symbolic name of the cron job. This name is used for human reference only and is generated automatically for cron jobs found on the system. This generally won''t matter, as Puppet will do its best to match existing cron jobs against specified jobs (and Puppet adds a comment to cron jobs it adds), but it is at least possible that converting from unmanaged jobs to managed jobs might require manual intervention. The names can only have alphanumeric characters plus the ''-'' character." This also has a similar restriction to the default run-parts behaviour, and I''m guessing the reason for the restriction is specifically because of run-parts behaviour. Maybe it should generate an error if you provide a name with a ''.'' in it. That might be a bug worth filing.
On Apr 21, 2007, at 7:01 AM, ADNET Ghislain wrote:> I dont know if i am missleaded but it seems to me that the cron > type does not accept names with a ''.'' in it ? I tried to add a > cron with a name cron1-$domainename and it does not accept it. If > i remove the ''.'' in the domain it work. I am using .22.3 anyone > seeing the same behavior ? If yes i will fill it as a bug.I don''t know why I did it this way, but it''s fixed now (in svn). -- At my lemonade stand I used to give the first glass away free and charge five dollars for the second glass. The refill contained the antidote. -- Emo Phillips --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
>> I dont know if i am missleaded but it seems to me that the cron >> type does not accept names with a ''.'' in it ? I tried to add a >> cron with a name cron1-$domainename and it does not accept it. If >> i remove the ''.'' in the domain it work. I am using .22.3 anyone >> seeing the same behavior ? If yes i will fill it as a bug. >> > > I don''t know why I did it this way, but it''s fixed now (in svn).What correlation does the cron type name have to any filesystem objects related to the cronjob? If you pass the ''.'' through, you will find that the cron fails silently on debian and ubuntu systems, and any system that has a similar run-parts implementation.
On Apr 22, 2007, at 11:00 PM, Daniel Lawson wrote:> > What correlation does the cron type name have to any filesystem > objects > related to the cronjob? If you pass the ''.'' through, you will find > that > the cron fails silently on debian and ubuntu systems, and any system > that has a similar run-parts implementation.Why would that happen? The only place the cron name is used right now is in a comment added above the cron job. Are you saying there''d be a problem with something in /etc/cron.daily or something like that? -- That was just a drill of the emergency y2k system. Had this been a real emergency, we would''ve also dumped a bucket of spiders on you and yelled out "civilization is collapsing!" --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
> Why would that happen? > > The only place the cron name is used right now is in a comment added > above the cron job. > > Are you saying there''d be a problem with something in /etc/cron.daily > or something like that? >Yes, exactly. The default behaviour of run-parts in debian and ubuntu is to ignore any files with a ''.'' in the filename. This may be the same behaviour on other distributions, I''m not sure. This has the annoying effect of ignoring any files with a ''.sh'' or ''.py'' extension, for example. This will effect all of the periodic cron fragment directories (cron.hourly, cron.daily etc). Furthermore, any files created in /etc/cron.d, at least as far as debian and ubuntu are concerned, must also follow the naming conventions used in run-parts. At least according to the manpages in etch and feisty! So it only matters if you''re actually using a file in one of those directories, and if the filename has a ''.'' in it. I had a quick look through the source, but I''m running an old version of puppet still, and I don''t really grok ruby very well so I''m not much use anyway :) It seems like the descriptive name is actually only used in a comment inside a single fragment file, so that''s probably not a problem.
On Apr 22, 2007, at 11:15 PM, Daniel Lawson wrote:> Yes, exactly. The default behaviour of run-parts in debian and ubuntu > is to ignore any files with a ''.'' in the filename. This may be the > same > behaviour on other distributions, I''m not sure. This has the annoying > effect of ignoring any files with a ''.sh'' or ''.py'' extension, for > example. This will effect all of the periodic cron fragment > directories (cron.hourly, cron.daily etc). > > Furthermore, any files created in /etc/cron.d, at least as far as > debian > and ubuntu are concerned, must also follow the naming conventions used > in run-parts. At least according to the manpages in etch and feisty!Ok.> So it only matters if you''re actually using a file in one of those > directories, and if the filename has a ''.'' in it. I had a quick look > through the source, but I''m running an old version of puppet still, > and > I don''t really grok ruby very well so I''m not much use anyway :) It > seems like the descriptive name is actually only used in a comment > inside a single fragment file, so that''s probably not a problem.There''s currently only a provider for normal crontab-style cron jobs, but I''m assuming at some point we''ll have providers for the cron.d directories and probably for /etc/crontab, so it might show up as a problem at some point. Should we restrict all cron names, then, or just have an extra validation step for the providers that would have problems? -- The most likely way for the world to be destroyed, most experts agree, is by accident. That''s where we come in; we''re computer professionals. We cause accidents. --Nathaniel Borenstein --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
> There''s currently only a provider for normal crontab-style cron jobs, > but I''m assuming at some point we''ll have providers for the cron.d > directories and probably for /etc/crontab, so it might show up as a > problem at some point. > > Should we restrict all cron names, then, or just have an extra > validation step for the providers that would have problems? >I''m generally in favour of consistent behaviour, but neither option provides that. I think the extra validation step, along with a useful error message, is the best method.
> There''s currently only a provider for normal crontab-style cron jobs, > but I''m assuming at some point we''ll have providers for the cron.d > directories and probably for /etc/crontab, so it might show up as a > problem at some point. > > Should we restrict all cron names, then, or just have an extra > validation step for the providers that would have problems? > > -- > The most likely way for the world to be destroyed, most experts agree, > is by accident. That''s where we come in; we''re computer professionals. > We cause accidents. --Nathaniel Borenstein > --------------------------------------------------------------------- > Luke Kanies | http://reductivelabs.com | http://madstop.com > > > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users >i think than when cron support will change to support other crontab systems like /etc/cron.d the parser should error on name containing non standard characters. I think this should be limited if you use this "to be written" cron type. Right now it is hard to make a crontab and use a domain name as $name. When each apache virtual host in your system is tied to cron not supporting the "." for the comment in the crontab will make the thing a little hard to code in a recipe. I had to have in my vhost define a ''crontabname'' and that does not sounds very handy. But this can be a thing to mark in the cron type for future extention so that a dev taking the code would see this warning if he wanted to change the cron type function. Also this would not affect the /etc/crontab mecanism. the /etc/cron.d is not standard to all *Nix i think ? In fact i do not know what mecanism is standard among unixes i only know debian/freebsd ;) -- Cordialement, Ghislain _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On Apr 23, 2007, at 2:21 AM, ADNET Ghislain wrote:>> > i think than when cron support will change to support other crontab > systems like /etc/cron.d the parser should error on name containing > non standard characters. I think this should be limited if you use > this "to be written" cron type.At this point, this is what''s happening. If someone writes an /etc/crontab provider, they can add further validation there. -- Every generation laughs at the old fashions, but follows religiously the new. -- Henry David Thoreau --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
>> i think than when cron support will change to support other crontab >> systems like /etc/cron.d the parser should error on name containing >> non standard characters. I think this should be limited if you use >> this "to be written" cron type. >> > > At this point, this is what''s happening. >i dont think so, it allready restrict the name of the cron type even if not needed in this situation. $name cannot contain a "."> If someone writes an /etc/crontab provider, they can add further > validation there. >it is not needed, in /etc/crontab the name of the type will not be important as it work the same way as the user crontab with one more column only, the only place where it could would be if you use the /etc/cron.daily/xxx or the /etc/cron.d/xxx files from what i heard -- Cordialement, Ghislain _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On Apr 26, 2007, at 3:34 PM, ADNET Ghislain wrote:> >>> i think than when cron support will change to support other >>> crontab systems like /etc/cron.d the parser should error on name >>> containing non standard characters. I think this should be >>> limited if you use this "to be written" cron type. >>> >> >> At this point, this is what''s happening. >> > i dont think so, it allready restrict the name of the cron type > even if not needed in this situation. > $name cannot contain a "."Sorry; this is what''s happening *in svn*.>> If someone writes an /etc/crontab provider, they can add further >> validation there. >> > it is not needed, in /etc/crontab the name of the type will not be > important as it work the same way as the user crontab with one more > column only, the only place where it could would be if you use the / > etc/cron.daily/xxx or the /etc/cron.d/xxx files from what i heards{/etc/crontab}{whatever crontab provider might have naming restrictions} My point is it can be handled per-provider, rather than in the type. -- Progress isn''t made by early risers. It''s made by lazy men trying to find easier ways to do something. --Robert Heinlein --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
>> i dont think so, it allready restrict the name of the cron type >> even if not needed in this situation. >> $name cannot contain a "." >> > > Sorry; this is what''s happening *in svn*. >oh! ok thanks ! This will simplify a lot my work on virtualhost ! :) i think this is a good way to handle this problem. -- Cordialement, Ghislain _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users